coding-agent-harness 1.0.0

package/templates/planning/visual_roadmap.md

@@ -0,0 +1,28 @@
+# [Task Name] - Visual Roadmap
+
+## Phase Graph
+
+```mermaid
+flowchart LR
+  PH01["PH-01 Plan"] --> PH02["PH-02 Implement"]
+  PH02 --> PH03["PH-03 Verify"]
+  PH03 --> PH04["PH-04 Review and Closeout"]
+```
+
+## Phase Table
+
+| Phase ID | Depends On | State | Completion | Output | Required Evidence | Evidence Status | Blocking Risk | Owner / Handoff |
+| --- | --- | --- | ---: | --- | --- | --- | --- | --- |
+| PH-01 | none | planned | 0 | Approved task plan and execution strategy | `task_plan.md`, `execution_strategy.md` | missing | none | coordinator |
+| PH-02 | PH-01 | planned | 0 | Scoped implementation or document update | diff, worker handoff, or artifact path | missing | [risk] | [owner] |
+| PH-03 | PH-02 | planned | 0 | Verification evidence | commands, logs, screenshots, or runtime proof | missing | [risk] | [owner] |
+| PH-04 | PH-03 | planned | 0 | Review disposition and closeout updates | `review.md`, progress update, ledger updates | missing | [risk] | coordinator |
+
+Allowed Evidence Status: missing, partial, present, waived.
+
+## Roadmap Notes
+
+- Use `missing` when no evidence has been checked.
+- Use `partial` when some evidence exists but required checks remain.
+- Use `present` when the phase has sufficient evidence for its current claim.
+- Use `waived` only when the reason and owner are recorded in `progress.md`.

package/templates/reference/adversarial-review-standard.md

@@ -0,0 +1,28 @@
+# Adversarial Review Standard
+
+## Purpose
+
+Define how plans, code changes, evidence, and closeout claims are challenged before work is accepted.
+
+## Rules
+
+1. Use adversarial review for high-risk changes, cross-cutting architecture, data migration, security-sensitive work, release blockers, and long-running tasks.
+2. Reviewers must act from an explicit `Reviewer Identity`, such as product risk reviewer, architecture reviewer, security reviewer, testing reviewer, or operator reviewer.
+3. Every review must include a `Confidence Challenge`: what assumption could be wrong, what evidence would disprove the claim, and what failure mode remains plausible.
+4. Findings must be classified as material or non-material. Material findings block closeout until closed with evidence, mitigated, classified as accepted-risk with owner rationale, or routed to a scoped follow-up.
+5. A reviewer may not accept a claim based only on implementation narration. The review must cite `Evidence Checked`.
+6. The owner must respond to each material finding with fix evidence, explicit rejection rationale, or a scoped follow-up.
+7. Closeout must include `Final Confidence Basis`, not just "review passed".
+
+## Required Artifacts
+
+- Review record with `Reviewer Identity`, review scope, and date.
+- `Confidence Challenge` section.
+- Findings table with severity, materiality, file or artifact reference, owner response, and status.
+- `Evidence Checked` list containing commands, test runs, screenshots, logs, PR links, or document paths.
+- Residual risk section for anything intentionally left open.
+- Final reviewer disposition: closed, closed-with-residual, or blocked.
+
+## Closeout Expectations
+
+Adversarial review is complete only when material findings are resolved or explicitly carried as residuals, the checked evidence is reproducible, and the closeout record explains why the final confidence is adequate for the delivery risk.

package/templates/reference/ci-cd-standard.md

@@ -0,0 +1,28 @@
+# CI/CD Standard
+
+## Purpose
+
+Define the continuous integration and deployment expectations that protect the repository from unverified changes and unsafe releases.
+
+## Rules
+
+1. Required checks must cover the project's real risk surface: build, lint, type checks, unit tests, integration tests, smoke tests, security scans, packaging, and deployment validation where applicable.
+2. CI configuration is product code. Changes to workflows, secrets, permissions, runners, release scripts, or deployment targets require review and evidence.
+3. A failing required check blocks merge unless the owner records an approved exception with scope, reason, expiry, and residual risk.
+4. Secrets must be referenced through the repository's approved secret store. Do not commit credentials, tokens, private keys, or generated environment dumps.
+5. Deployment jobs must identify the target environment, artifact version, rollback path, and post-deploy verification.
+6. Flaky checks must be tracked as defects. Re-running CI is not a substitute for diagnosis when the same failure pattern repeats.
+7. CI evidence used for closeout must be fresh enough for the submitted change set.
+
+## Required Checklist
+
+- Required checks are named and mapped to the risks they cover.
+- Branch protection or merge policy is documented.
+- Secrets, permissions, and deployment environments have owners.
+- Release artifacts are traceable to commit SHA or version.
+- Rollback or remediation path is known before production deployment.
+- CI failure exceptions include owner, expiry, evidence, and residual.
+
+## Closeout Expectations
+
+Closeout must list the required checks that passed, any checks not run, the reason for each omission, and the residual risk. Deployment closeout must include post-deploy evidence from the target environment.

package/templates/reference/delivery-operating-model-standard.md

@@ -0,0 +1,28 @@
+# Delivery Operating Model Standard
+
+## Purpose
+
+Define how work is organized across owners, agents, branches, reviews, and release gates before implementation starts.
+
+## Rules
+
+1. Select the operating model before coding: solo owner, coordinator plus workers, review-only workers, or release steward model.
+2. Work must have a named coordinator when multiple agents or humans touch related surfaces.
+3. Shared files, global styles, build configuration, schemas, and release scripts require coordinator ownership. Workers must not make unplanned edits to shared surfaces.
+4. Parallel work must be split by low-conflict boundaries such as module, route, package, document area, or test surface.
+5. Each worker must have a scope statement, allowed paths, forbidden paths, expected artifacts, and handoff format.
+6. The coordinator owns final merge, conflict resolution, evidence consolidation, and residual risk summary.
+7. The operating model must identify which decisions can be made by workers and which require coordinator approval.
+
+## Required Artifacts
+
+- Delivery model statement in the task plan.
+- Scope map for each owner or worker.
+- Shared-surface ownership list.
+- Handoff requirements for code, tests, review notes, and evidence.
+- Merge and release gate checklist.
+- Residual risk owner for unresolved items.
+
+## Closeout Expectations
+
+Closeout must show that all worker handoffs were reviewed, shared-surface changes were reconciled by the coordinator, required checks were run from the integration branch, and remaining residuals have owners.

package/templates/reference/docs-library-standard.md

@@ -0,0 +1,28 @@
+# Docs Library Standard
+
+## Purpose
+
+Define how the project documentation library is organized so agents can find current standards, plans, evidence, and historical context without relying on chat history.
+
+## Rules
+
+1. Keep `AGENTS.md` as the routing and charter entry point. Store durable policy in reference documents, not in scattered prompts.
+2. Keep active task plans under the planning area and stable operating standards under the reference area.
+3. Each durable document must state its purpose, owner or maintenance rule, and when an agent should read it.
+4. Link to source artifacts instead of copying long logs or duplicating facts across files.
+5. Archive stale records instead of deleting them when they explain historical decisions.
+6. Do not mix private runtime state, credentials, personal notes, or generated caches into the public docs library.
+7. Documentation updates that change process or behavior must be reflected in the relevant index or routing file.
+
+## Required Checklist
+
+- Entry points identify current reference standards, planning templates, SSoT files, walkthroughs, and ledgers.
+- Active documents have clear names and stable paths.
+- Archive boundaries are documented.
+- Generated or private artifacts are excluded or explicitly separated.
+- Cross-links point to the source of truth for each subject.
+- New standards include closeout and evidence expectations.
+
+## Closeout Expectations
+
+Documentation closeout must list changed docs, state whether routing indexes were updated, identify any obsolete docs archived or left in place, and record residual documentation gaps.

package/templates/reference/engineering-standard.md

@@ -0,0 +1,29 @@
+# Engineering Standard
+
+## Purpose
+
+Define baseline engineering expectations for code, configuration, tests, and maintainability in this repository.
+
+## Rules
+
+1. Prefer the repository's existing architecture, language, framework, and helper patterns over new abstractions.
+2. Keep changes scoped to the task. Do not refactor unrelated code or clean up unrelated files during feature work.
+3. Design changes around clear ownership boundaries: module, package, API, data contract, UI surface, or operational script.
+4. Treat configuration, migrations, generated artifacts, and scripts as first-class engineering surfaces with review and tests where risk warrants it.
+5. Make behavior explicit through typed contracts, structured data, schema validation, or tests rather than fragile string conventions.
+6. Avoid hidden global state, broad side effects, and undocumented environment assumptions.
+7. Include observability or diagnostics when a failure would otherwise be hard to explain.
+
+## Required Checklist
+
+- Scope and ownership boundary are clear.
+- Existing local patterns were followed or the departure is justified.
+- User-facing or API-facing behavior has tests or documented verification.
+- Error handling covers expected failure modes.
+- Configuration and environment assumptions are documented.
+- Security, privacy, and data-retention implications were considered when relevant.
+- Residual technical debt is recorded with owner and reason.
+
+## Closeout Expectations
+
+Engineering closeout must name the changed surfaces, summarize the behavioral impact, list verification evidence, and identify any residual risk or follow-up that should not be hidden inside implementation notes.

package/templates/reference/execution-workflow-standard.md

@@ -0,0 +1,29 @@
+# Execution Workflow Standard
+
+## Purpose
+
+Define the standard lifecycle for non-trivial work from intake through planning, implementation, verification, review, and closeout.
+
+## Rules
+
+1. Start by identifying goal, scope, constraints, allowed paths, forbidden paths, acceptance criteria, and expected evidence.
+2. Create or update a task plan before implementation when the work spans multiple files, multiple agents, external systems, or user-facing behavior.
+3. Record important discoveries in the task artifacts instead of relying on transient chat context.
+4. Implement in small reviewable slices and keep the plan current when scope changes.
+5. Run checks that match the risk surface before claiming completion.
+6. Route material findings through review and do not bury unresolved issues in summaries.
+7. Close the loop by updating walkthrough, SSoT, regression, ledger, or docs artifacts when the work changes durable project knowledge.
+
+## Required Checklist
+
+- Goal, scope, acceptance criteria, and constraints are written down.
+- Current repo state and ownership boundaries were checked.
+- Implementation notes identify changed surfaces.
+- Required checks and evidence are captured.
+- Review status and material findings are recorded.
+- Residuals are explicit and assigned.
+- Closeout artifacts are updated when required.
+
+## Closeout Expectations
+
+Closeout must provide a concise change summary, evidence checked, checks not run with reasons, review outcome, residual risk, and any durable docs or ledger updates made during the task.

package/templates/reference/harness-ledger-standard.md

@@ -0,0 +1,26 @@
+# Harness Ledger Standard
+
+## Purpose
+
+Define when and how the Harness Ledger records durable changes to the agent operating system for this project.
+
+## Rules
+
+1. Update the Harness Ledger when a task changes standards, routing, planning workflow, review workflow, regression gates, ownership boundaries, or reusable lessons.
+2. The ledger is not a daily diary. It records durable operating context that future agents need in order to avoid repeating discovery work.
+3. Each ledger entry must identify the task, date, changed harness surface, evidence, and follow-up owner if any.
+4. Keep entries short and link to task plans, walkthroughs, pull requests, review records, or evidence files.
+5. Do not store secrets, personal data, large logs, or raw generated output in the ledger.
+6. If a lesson changes a reference standard, record both the lesson and the reference update.
+7. If no ledger update is needed, closeout should say why.
+
+## Required Artifacts
+
+- Ledger entry for durable harness changes.
+- Links to changed standards, SSoT files, walkthroughs, or PRs.
+- Evidence reference for the change.
+- Residual or follow-up owner when the harness change is partial.
+
+## Closeout Expectations
+
+Task closeout must state whether the Harness Ledger was updated. When updated, cite the entry. When not updated, explain that the task did not change durable harness behavior.

package/templates/reference/long-running-task-standard.md

@@ -0,0 +1,28 @@
+# Long-Running Task Standard
+
+## Purpose
+
+Define the contract required before an agent performs extended autonomous work across multiple steps, files, checks, or reviews.
+
+## Rules
+
+1. A long-running task requires an explicit contract before execution begins.
+2. The contract must define goal, scope, allowed paths, forbidden paths, acceptance criteria, expected evidence, review cadence, pause conditions, and stop conditions.
+3. The agent must keep progress in task artifacts, not only in chat messages.
+4. Material scope changes require contract update or user confirmation before continuing.
+5. The agent must preserve unrelated user or worker changes and must not revert files outside its scope.
+6. Review checkpoints must challenge direction, evidence quality, and residual risk before final closeout.
+7. Completion requires verification evidence and a closeout record, not just implementation completion.
+
+## Required Artifacts
+
+- Long-running task contract.
+- Task plan with current state, active slice, and acceptance criteria.
+- Progress log or checklist.
+- Findings or review record with material findings.
+- Evidence list with commands, test results, screenshots, logs, or affected paths.
+- Residual risk and follow-up section.
+
+## Closeout Expectations
+
+Closeout must confirm the contract scope was honored, list evidence checked, identify checks not run, resolve or record material findings, and state the final residual risk. If the task stopped early, closeout must explain the stop condition and next safe action.

package/templates/reference/regression-ssot-governance.md

@@ -0,0 +1,28 @@
+# Regression SSoT Governance
+
+## Purpose
+
+Define how regression knowledge is added, maintained, retired, and used as release evidence.
+
+## Rules
+
+1. The Regression SSoT is the source of truth for critical surfaces, required checks, cadence, owners, and known gaps.
+2. Add or update regression entries when a bug escapes, a user-facing workflow changes, a contract changes, or a new critical surface appears.
+3. Each regression entry must name the risk it protects, the check that covers it, the cadence, and the evidence expected from a passing run.
+4. Retire regression entries only when the protected behavior is removed or replaced by stronger coverage.
+5. Do not mark a surface covered when the check only exercises a mock path that cannot catch the real failure.
+6. Flaky, skipped, or manual-only coverage must be visible as residual risk.
+7. Release closeout must use the current Regression SSoT rather than an ad hoc checklist.
+
+## Required Checklist
+
+- Critical surfaces are listed with owners.
+- Required checks are mapped to surfaces and risk.
+- Cadence is defined for local, PR, release, and post-deploy verification where relevant.
+- Manual checks include exact steps and evidence format.
+- Known gaps, flaky checks, and disabled checks are recorded as residuals.
+- Changes to regression policy are reflected in the Harness Ledger when durable.
+
+## Closeout Expectations
+
+Regression closeout must cite the SSoT entries used, show fresh evidence for required checks, explain skipped checks, and record any new or changed residual risk.

package/templates/reference/repo-governance-standard.md

@@ -0,0 +1,29 @@
+# Repository Governance Standard
+
+## Purpose
+
+Define repository-level rules for branches, commits, pull requests, ownership, generated files, and merge safety.
+
+## Rules
+
+1. Respect the current worktree state. Do not revert or overwrite unrelated changes from other people or agents.
+2. Use task-scoped branches and worktrees for non-trivial changes, especially when multiple workers are active.
+3. Keep commits focused on the requested scope and avoid mixing unrelated cleanup with feature work.
+4. Generated files, caches, build output, local runtime state, and secrets must be ignored or stored in the approved location.
+5. Pull requests must describe intent, changed surfaces, checks run, checks not run, review status, and residual risk.
+6. Required checks and material review findings block merge unless an approved exception is recorded.
+7. Merge or release ownership must be explicit when several branches or workers contribute to the same outcome.
+
+## Required Checklist
+
+- Branch and worktree ownership are clear.
+- Allowed and forbidden paths are respected.
+- Dirty worktree state was checked before edits.
+- Generated and private files are not accidentally staged.
+- PR summary includes evidence and residuals.
+- Review findings are resolved or explicitly accepted.
+- Merge strategy and rollback or revert path are understood.
+
+## Closeout Expectations
+
+Repository closeout must list changed paths, confirm scope boundaries were honored, report git status relevant to the task, summarize checks, and identify unrelated dirty files left untouched.

package/templates/reference/review-routing-standard.md

@@ -0,0 +1,29 @@
+# Review Routing Standard
+
+## Purpose
+
+Define when work needs review, which reviewer identity is appropriate, and how review results are routed back into implementation and closeout.
+
+## Rules
+
+1. Route review based on risk, not habit. Architecture, security, data, release, UX, and test-risk changes need different reviewer identities.
+2. Every routed review must name `Reviewer Identity`, review scope, expected evidence, and decision authority.
+3. Use adversarial review when a normal pass/fail review would not sufficiently challenge assumptions.
+4. Material findings must be routed to an owner and tracked until closed with evidence, mitigated, classified as accepted-risk, or moved to a follow-up with approval.
+5. Reviewers must list `Evidence Checked`; unverified claims are questions, not conclusions.
+6. The implementation owner is responsible for reconciling conflicting reviewer feedback.
+7. Closeout must include the final review disposition and `Final Confidence Basis`.
+
+## Required Checklist
+
+- Review trigger and reviewer identity are documented.
+- Scope and files or artifacts under review are listed.
+- Required evidence is available to the reviewer.
+- Material findings are labeled and owner-routed.
+- Non-material suggestions are separated from blockers.
+- Residuals have rationale and owner.
+- Final disposition is recorded.
+
+## Closeout Expectations
+
+Review routing is complete when all required reviewers have responded or an explicit residual explains the missing review, material findings are resolved or accepted, and final confidence is grounded in checked evidence.

package/templates/reference/testing-standard.md

@@ -0,0 +1,28 @@
+# Testing Standard
+
+## Purpose
+
+Define the minimum verification required before an agent claims that a change is complete.
+
+## Rules
+
+1. Tests must match the change risk. Use unit tests for isolated logic, integration tests for contracts, end-to-end or smoke tests for user workflows, and manual verification for surfaces automation cannot cover.
+2. Do not claim success from tests that did not exercise the changed behavior.
+3. A skipped, flaky, or unavailable test is residual risk and must be recorded with a reason.
+4. When fixing a bug, add or update coverage that would have caught the failure unless the cost is clearly unjustified and documented.
+5. For UI changes, verify realistic viewport and interaction states when layout, navigation, or user workflow changed.
+6. For data, migration, security, or deployment changes, include evidence from the real contract or environment where feasible.
+7. Final summaries must distinguish checks run, checks not run, and evidence inspected.
+
+## Required Checklist
+
+- Changed behavior is mapped to verification method.
+- Required checks were run from the correct branch or worktree.
+- Test output, logs, screenshots, or command results are captured.
+- Manual checks include exact path and expected result.
+- Known gaps and residual risk are recorded.
+- Regression SSoT is updated when the change adds or changes a protected surface.
+
+## Closeout Expectations
+
+Testing closeout must list commands or manual checks, summarize results, identify untested risk, and explain why the evidence is sufficient for the requested acceptance criteria.

package/templates/reference/walkthrough-standard.md

@@ -0,0 +1,28 @@
+# Walkthrough Standard
+
+## Purpose
+
+Define the closeout walkthrough that converts implementation work into durable project memory and reviewable evidence.
+
+## Rules
+
+1. Write a walkthrough for non-trivial tasks, long-running tasks, releases, cross-cutting changes, or work that future agents will need to understand.
+2. A walkthrough must explain what changed, why it changed, how it was verified, what review found, and what residual risk remains.
+3. Do not paste large raw logs. Link to evidence files, commands, PRs, screenshots, or CI runs.
+4. Material findings and their resolution must be visible.
+5. Lessons that change future behavior must be routed to the appropriate SSoT, reference standard, or Harness Ledger.
+6. Walkthroughs must be written from the final integrated state, not from a single worker's partial view.
+7. If work is incomplete, the walkthrough must identify the next safe action and stop reason.
+
+## Required Artifacts
+
+- Walkthrough record with date, owner, task, changed surfaces, and links.
+- Evidence summary with checks run and checks not run.
+- Review summary with material findings and disposition.
+- Residual risk section.
+- Lesson or follow-up section.
+- Links to updated SSoT, Regression SSoT, or Harness Ledger entries when applicable.
+
+## Closeout Expectations
+
+Walkthrough closeout is complete when a future agent can understand the delivery state, reproduce the important evidence trail, and know which residuals or lessons still matter.

package/templates/reference/worktree-standard.md

@@ -0,0 +1,28 @@
+# Worktree Standard
+
+## Purpose
+
+Define how git worktrees are used to isolate implementation, support parallel agents, and protect unrelated work.
+
+## Rules
+
+1. Use a separate worktree for non-trivial feature work when the main checkout is dirty, multiple workers are active, or the task needs isolated verification.
+2. Name branches and worktrees with task intent, not vague labels.
+3. Before editing, record the current branch, worktree path, git status, allowed paths, and forbidden paths.
+4. Workers must not edit outside their assigned scope unless the coordinator updates the plan.
+5. Shared files must be owned by the coordinator or merged through an explicit integration pass.
+6. Run verification from the worktree that contains the final integrated changes.
+7. Clean up merged worktrees only after the branch state, commits, and any needed artifacts are confirmed.
+
+## Required Checklist
+
+- Worktree path and branch are recorded.
+- Scope boundaries are documented.
+- Dirty state and unrelated changes are noted before work.
+- Dependencies are installed or verified in the worktree when needed.
+- Handoff includes changed paths, checks, review notes, and residuals.
+- Integration branch is verified after merging worker output.
+
+## Closeout Expectations
+
+Worktree closeout must identify the branch and worktree used, list changed paths, confirm unrelated changes were preserved, report verification from the final state, and state whether the worktree was retained or cleaned up.

package/templates/regression/Cadence-Ledger.md

@@ -0,0 +1,41 @@
+# Cadence Ledger
+
+## Purpose
+
+Map change scopes to required regression gates and recurring check cadence. This file turns Regression SSoT gates into an operating schedule.
+
+## Status Legend
+
+| Status | Meaning | Required Next Step |
+| --- | --- | --- |
+| active | Cadence rule is enforced. | Run when triggered and record evidence. |
+| paused | Rule is temporarily disabled. | Record approver, reason, and resume date. |
+| failing | Latest scheduled run failed. | Assign fix owner and block affected closeout. |
+| replaced | Rule has a newer owner or gate. | Link replacement. |
+| archived | Rule is historical. | Preserve final evidence and replacement pointer. |
+
+## Cadence Rules
+
+| ID | Change Scope or Trigger | Required Gates | Minimum Evidence Depth | Frequency | Owner | Status | Latest Run | Next Run or Trigger | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| C-000 | paths, modules, labels, release, or schedule | RG-000, RG-001 | E2 | per PR / daily / release | owner | active | YYYY-MM-DD evidence path | next trigger | none |
+
+## Run Log
+
+| Run ID | Date | Trigger | Gates Run | Result | Evidence | Follow-up |
+| --- | --- | --- | --- | --- | --- | --- |
+| CR-YYYY-MM-DD-001 | YYYY-MM-DD | PR, release, schedule, or manual | RG-000 | pass / fail / waived | path, CI run, log, or screenshot | none |
+
+## Routing Rules
+
+1. Every active Regression SSoT gate that must run repeatedly should have a cadence rule.
+2. Path-based triggers must be specific enough for agents to choose the right checks without guessing.
+3. Failed cadence runs remain visible until a passing replacement run or documented waiver exists.
+4. Waived runs must link the corresponding Regression SSoT waiver.
+5. Release closeout must cite the latest run log entries for release-blocking gates.
+
+## Archive Rules
+
+- Keep the current release cycle and any failing runs in this file.
+- Archive older passing runs after their release or milestone is closed.
+- Preserve run ID, trigger, result, and evidence link in archived records.

package/templates/ssot/Delivery-SSoT.md

@@ -0,0 +1,43 @@
+# Delivery SSoT
+
+## Purpose
+
+Coordinate cross-role, cross-repository, or multi-module delivery work. This file is the active contract for who is moving which slice, what must synchronize, and what blocks release.
+
+## Status Legend
+
+| Status | Meaning | Required Next Step |
+| --- | --- | --- |
+| shaping | Delivery scope is being split or sequenced. | Define slices, owners, and integration points. |
+| ready | Delivery plan is accepted. | Open worktrees, branches, or tickets as needed. |
+| active | One or more slices are in progress. | Update sync points and blockers. |
+| integration | Slices are being merged or reconciled. | Run integration checks and resolve conflicts. |
+| blocked | Delivery cannot proceed. | Record blocker owner and unblock condition. |
+| released | Delivery is complete and closeout exists. | Keep links until the release is no longer current. |
+| archived | Delivery is historical. | Keep archive pointer and release evidence. |
+
+## Active Deliveries
+
+| ID | Delivery | Scope | Coordinator | Status | Slices | Integration Point | Release Gate | Closeout | Residual | Updated |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| D-000 | Short delivery title | repo, module, or release scope | owner | ready | M-000, M-001 | branch, PR, or merge window | RG-000 or release checklist | pending | none | YYYY-MM-DD |
+
+## Sync Points
+
+| ID | When | Participants | Required Input | Decision or Output | Owner |
+| --- | --- | --- | --- | --- | --- |
+| SYNC-000 | YYYY-MM-DD or trigger | owners | plans, diffs, evidence, or blockers | merge decision, split decision, or release decision | coordinator |
+
+## Routing Rules
+
+1. Use Delivery SSoT when work spans more than one owner, module, repository, or release gate.
+2. Keep module ownership in Module Registry and link module IDs from delivery rows.
+3. A delivery cannot move to `released` while any release-blocking slice remains unresolved.
+4. Integration conflicts, shared-file edits, and `accepted-risk` decisions must be visible here even if detailed elsewhere.
+5. The coordinator owns this file; individual workers own their slice plans and evidence.
+
+## Archive Rules
+
+- Archive released deliveries after their release evidence is stable and no active slice depends on them.
+- Keep an archive pointer in the active table for recently released work if follow-up is expected.
+- Preserve blocker history when archiving failed, canceled, or deferred deliveries.

package/templates/ssot/Feature-SSoT.md

@@ -0,0 +1,43 @@
+# Feature SSoT
+
+## Purpose
+
+Maintain the authoritative feature queue for agent-executed work. This file answers what is planned, who owns it, what evidence is required, and whether the work is safe to close.
+
+## Status Legend
+
+| Status | Meaning | Required Next Step |
+| --- | --- | --- |
+| intake | Candidate feature is captured but not shaped. | Clarify goal, owner, and acceptance evidence. |
+| ready | Scope and acceptance criteria are clear. | Create or link the task plan. |
+| active | Implementation or review is in progress. | Keep plan, evidence, and residuals current. |
+| blocked | Feature cannot proceed. | Record blocker owner and unblock condition. |
+| verify | Work is implemented and waiting for evidence. | Run required checks and update Regression SSoT. |
+| shipped | Feature is delivered and walkthrough is complete. | Keep row until no longer operationally relevant. |
+| archived | Feature is historical. | Keep archive pointer and final evidence link. |
+
+## Active Features
+
+| ID | Feature | User Outcome | Owner | Status | Priority | Task Plan | Acceptance Evidence | Regression Gate | Walkthrough | Residual | Updated |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| F-000 | Short feature title | Observable user or operator result | owner | ready | P1 | docs/09-PLANNING/TASKS/.../task_plan.md | command, test, screenshot, or review path | RG-000 | pending | none | YYYY-MM-DD |
+
+## Intake Queue
+
+| Candidate | Source | Decision Needed | Owner | Due |
+| --- | --- | --- | --- | --- |
+| Short request title | issue, roadmap, user request, or review | accept, split, defer, or reject | owner | YYYY-MM-DD |
+
+## Routing Rules
+
+1. Add a feature row before implementation starts unless the task is a documented emergency fix.
+2. Use one row per deliverable outcome, not one row per commit.
+3. Link the task plan before moving a feature to `active`.
+4. Link regression evidence before moving a feature to `shipped`.
+5. Record `accepted-risk` explicitly; `none` means no known residual risk after verification.
+
+## Archive Rules
+
+- Keep shipped rows visible through the next release or verification cycle.
+- Move older shipped rows to the project archive with their final walkthrough and regression evidence.
+- Do not archive blocked rows until the blocker is resolved, accepted, or explicitly abandoned.

package/templates/ssot/Lessons-SSoT.md

@@ -0,0 +1,44 @@
+# Lessons SSoT
+
+## Purpose
+
+Track reusable lessons discovered during closeout and route them into standards, templates, checkers, or explicit no-action decisions.
+
+## Status Legend
+
+| Status | Meaning | Required Next Step |
+| --- | --- | --- |
+| candidate | Lesson was proposed during review or walkthrough. | Decide whether it is reusable. |
+| accepted | Lesson is valid and needs a durable change. | Assign implementation target and owner. |
+| applied | Durable change has landed. | Link changed file, checker, or template. |
+| rejected | Lesson is not reusable or not worth adopting. | Record reason. |
+| superseded | A newer lesson replaces this one. | Link replacement. |
+| archived | Lesson is historical. | Keep detail doc and final disposition. |
+
+## Active Lessons
+
+| ID | Lesson | Source | Type | Owner | Status | Target Change | Detail Doc | Evidence | Updated |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| L-YYYY-MM-DD-001 | Short lesson title | walkthrough, review, incident, or verifier | ref-change / new-doc / arch-process-change | owner | candidate | file, checker, template, or no-action | docs/01-GOVERNANCE/lessons/...md | source link | YYYY-MM-DD |
+
+## Type Routing
+
+| Type | Use When | Required Artifact |
+| --- | --- | --- |
+| ref-change | Existing standard, template, or checker needs an update. | `templates/lessons/lesson-ref-change.md` detail doc. |
+| new-doc | A missing durable reference document is needed. | `templates/lessons/lesson-new-doc.md` detail doc. |
+| arch-process-change | Operating model, phase gate, ownership, or architecture process needs to change. | `templates/lessons/lesson-arch-process-change.md` detail doc. |
+
+## Routing Rules
+
+1. Walkthrough closeout must record whether a lessons check was performed.
+2. Do not create a lesson for one-off trivia; create one only when a future agent could repeat the failure or benefit from the rule.
+3. Accepted lessons must name the durable target: reference doc, template, checker, workflow, or operating model.
+4. `applied` requires evidence of the durable change, not just agreement in chat.
+5. Rejected lessons must explain why no durable change is needed.
+
+## Archive Rules
+
+- Keep candidate and accepted lessons in this file until resolved.
+- Archive applied, rejected, or superseded lessons after the next closeout cycle.
+- Preserve the detail doc and source walkthrough link for every archived lesson.