feat(directives): scavenge sweep 4/5 (tracks + commands + styleguides + todos): 18 batch-4 directives + concurrent worker batches

conductor/directives/spec_template_required_6_sections/meta.md

@@ -0,0 +1,7 @@
+# spec_template_required_6_sections
+
+## v1
+
+**Why this iteration:** Lifted from `.opencode/agents/tier1-orchestrator.md:89-102 (Spec Template — REQUIRED sections)` and reinforced by `.opencode/commands/conductor-new-track.md:59-89 (Step 5 — Create spec.md)`. The 6-section template (Overview + Current State Audit + Goals + Functional Reqs + Non-Functional Reqs + Architecture Ref + Out of Scope) is the canonical scaffold every spec.md must follow; it is not yet encoded as a directive.
+**Source:** `.opencode/agents/tier1-orchestrator.md:89-102 + .opencode/commands/conductor-new-track.md:59-89`
+**Lifted:** 2026-07-03 scavenge sweep batch 5/5: guides + role prompts + transcripts

conductor/directives/spec_template_required_6_sections/v1.md

@@ -0,0 +1,65 @@
+# Track spec.md MUST include the 6 canonical sections (Current State Audit, Goals, Functional/Non-Functional Reqs, Architecture Reference, Out of Scope)
+
+From `.opencode/agents/tier1-orchestrator.md` §"Spec Template (REQUIRED sections)" (lines 89-102)
+and `.opencode/commands/conductor-new-track.md` Step 5 (lines 59-89):
+
+> ```markdown
+> # Track Specification: {Title}
+>
+> ## Overview
+> ## Current State Audit (as of {commit_sha})
+> ### Already Implemented (DO NOT re-implement)
+> ### Gaps to Fill (This Track's Scope)
+> ## Goals
+> ## Functional Requirements
+> ## Non-Functional Requirements
+> ## Architecture Reference
+> ## Out of Scope
+> ```
+
+## The 6 canonical sections
+
+Every `spec.md` MUST contain these 6 top-level sections in this order:
+
+1. **Overview** — one-paragraph description of the track's purpose.
+2. **Current State Audit** — anchored to a commit SHA, with two sub-sections:
+   - `Already Implemented (DO NOT re-implement)` — file:line refs to existing
+     features that look in-scope but are not (the "why we don't re-build this")
+   - `Gaps to Fill (This Track's Scope)` — what this track adds
+3. **Goals** — specific, measurable goals (one bullet per goal).
+4. **Functional Requirements** — detailed behavior requirements, written as
+   testable statements.
+5. **Non-Functional Requirements** — performance, security, observability,
+   thread-safety, etc.
+6. **Architecture Reference** — link to the relevant `docs/guide_*.md`
+   sections (the file:line refs into the architecture docs) that the
+   implementing agent should fall back to.
+
+The 7th section is **`## Out of Scope`** — what this track will NOT do
+(boundary setting for the implementing agent).
+
+## Why
+
+Spec mismatch is the #1 cause of track rework. An agent implementing a track
+without a "Current State Audit" anchors to imagined features and re-implements
+what already exists. An agent implementing without "Architecture Reference"
+makes up the threading model or invents new patterns instead of using the
+documented ones. An agent implementing without "Out of Scope" creeps the
+track into adjacent work.
+
+The 6 sections (plus Out of Scope) are the defense-in-depth against these
+failure modes. They must be present in every spec.md, not just the high-priority
+ones.
+
+## Verification
+
+A spec.md is incomplete (and the track should not be launched) if any of the
+6 sections is missing or is a placeholder (e.g., "TBD" or "see another doc").
+The `implementing_plan` pass should treat any missing section as a red-flag
+that the spec was rushed.
+
+## See also
+
+- `conductor/workflow.md` §"Tier 1 Track Initialization Rules" §2 (Spec format)
+- `docs/handoffs/PROMPT_FOR_TIER_1.md` — concrete example of the 6-section
+  structure in a real handoff