Rejected Approaches
Rejected approaches are retained so future work does not reopen settled constraints without evidence.
Summary
Section titled “Summary”A rejected approach is not forgotten. It remains visible with the reason it was rejected.
Why This Matters
Section titled “Why This Matters”Teams lose time when old debates restart without new evidence. This page keeps the rejection context close to the active architecture.
Evidence Sources
Section titled “Evidence Sources”- Automation plan
- Harness docs
- Generated decisions and risks
- BOARD001C and BOARD001D task outcomes
What Happened
Section titled “What Happened”Several approaches were considered or naturally tempting but rejected because they weaken source control, safety, or reuse.
Decision / Lesson / Pattern
Section titled “Decision / Lesson / Pattern”Rejected approaches should be re-opened only when a new accepted task explicitly changes the evidence.
What To Preserve
Section titled “What To Preserve”- Notion as source of truth: rejected.
- NotebookLM as source of truth: rejected.
- Chat memory alone as source of truth: rejected.
- Board automation writing into
foryoutune-dev: rejected. - Raw source copying into board pages: rejected.
- Cross-repo write automation before v0.1 stability: rejected.
What To Recheck
Section titled “What To Recheck”- Whether a rejected approach has new evidence.
- Whether a future SaaS project has different constraints.
- Whether the rejection should become deprecated rather than active.
Carry Forward
Section titled “Carry Forward”Use docs/history-templates/rejected-approach.template.md when rejecting a meaningful future option.