bad-code: keep technical teardown from becoming a stale parallel architecture doc

[flyingrobots]

Observed while committing docs/TECHNICAL_TEARDOWN.md on PR #539.

The teardown is valuable as a branch-state orientation document, but it overlaps the existing authoritative doc map: README.md, docs/GUIDE.md, docs/ARCHITECTURE.md, docs/BEARING.md, and the active design packets. It also names the holmes-weslaw-ingest-gates branch and June 1, 2026 explicitly.

Risk: future readers may treat a stale teardown snapshot as architecture authority after the branch has moved on.

Acceptance criteria:

• Decide whether docs/TECHNICAL_TEARDOWN.md is a maintained orientation doc, a dated snapshot, or a temporary review artifact.
• If maintained, wire it into the docs front door and define what must update when behavior/architecture changes.
• If snapshot-only, mark that status clearly near the top and avoid letting it override docs/ARCHITECTURE.md or docs/BEARING.md.
• If temporary, remove or archive it after the PR has served its review purpose.

[coderabbitai]

🔗 Related PRs

#475 - Merge-worthy unmerged branches into omnibus reconciliation branch [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!