@nurix/etna 0.19.66 → 0.19.68

package/data/harnesses/apollo/skills/documentation/templates/implementation-map.md

@@ -1,42 +0,0 @@
-# Implementation Map (docs/operations/implementation-map.md)
-
-Truth document. Use for: **the cold-start execution contract of a project being built from its documented design** — one per repo, at `docs/operations/implementation-map.md`. It is authored by the **executing session at build start**, never generated at design time: build order is derived from the repo's actual feature docs and their stated dependencies, and a design-time prediction of it goes stale the day reality disagrees. It lives in operations because it says *how to proceed*, not *what is true of the design*.
-
-## Writing the map
-
-- **Derive waves from the feature docs** — their stated dependencies plus shared foundations (schema before routes, auth before anything it guards). A wave groups features that can build together; the order reflects foundations, not product importance.
-- **A wave's done criterion is observable** — its plans' verification gates passed, the suite green, a named surface driveable. Never "feels complete".
-- **Authority order names this repo's own docs, most specific wins.** A contradiction between documents is repaired in the owning truth doc *before* code — never reinterpreted while planning.
-- **Plans are records, not an execution queue.** The map points at the active wave's dated plan; historical plans are read only when a truth doc cites them as provenance.
-- **Update in place as waves complete** — the map states the current build position in present tense; the journey lives in the plans and changelog entries.
-
-```
-# {Project} implementation map
-
-## Cold-start contract
-
-{One paragraph: what a fresh session asked to "build this" is expected to do with this
-repository — plan, gate, implement, verify, in what granularity — and the statement that it
-needs nothing outside the repo.}
-
-## Authority order
-
-When documents disagree:
-
-1. {The constitutional docs — guardrails, non-goals, PRD-class documents}
-2. The most specific feature doc under `docs/features/`
-3. {The structural truth docs — domain model, storage schema, API contracts}
-4. The dated plan for the active wave
-5. Owned source files as implementation evidence
-
-## Waves
-
-| Wave | Features | Depends on | Done when |
-| - | - | - | - |
-| 1 | {docs/features/x.md, docs/features/y.md} | — | {observable criterion} |
-| 2 | {…} | 1 | {…} |
-
-## Current position
-
-{One line per wave: complete · in progress ([plan](../history/plans/YYYY-MM-DD-slug.md)) · pending.}
-```

package/data/harnesses/apollo/skills/documentation/templates/journal.md

@@ -1,13 +0,0 @@
-# Journal (docs/history/journal.md)
-
-Record — append-only. Use for: durable mid-execution knowledge — a fact discovered while building that some owning doc will eventually carry, captured the moment it exists so it survives the session. A row is resolved by landing in its owning doc: the row is deleted and the changelog entry cites it. The file stays short by construction; a journal that only grows is a queue nobody drains.
-
-One line per fact. Never narrative, never progress notes (progress lives in the plan), never user preferences (those go to the runtime's memory store).
-
-```
-# Journal
-
-Append-only capture of mid-execution knowledge — one line per fact, written the moment it exists, resolved by landing in its owning doc (delete the row, cite it in the changelog entry). Format: `YYYY-MM-DD · <area> · <one-line fact> → lands-in: <owning doc | backlog | memory>`
-
-- YYYY-MM-DD · {area} · {one-line fact} → lands-in: {owning doc | backlog | memory}
-```

package/data/harnesses/apollo/skills/documentation/templates/memory-main.md

@@ -1,25 +0,0 @@
-# Scaffold: docs/memory/main.md
-
-Baseline scaffold — created if missing (the `maintenance` agent's baseline calls this). Target file: `docs/memory/main.md`.
-
-```
----
-type: project-memory
-owner: main-agent
-description: Project-wide patterns and conventions confirmed in this codebase. Project facts only — user-centric facts go in ~/.claude/.
----
-
-# Main Agent — Project Memory
-
-Append entries below, oldest at bottom. Format:
-
-## YYYY-MM-DD — {topic}
-
-{1-3 line fact, with file paths or references where relevant}
-
----
-
-## {today} — Baseline
-
-Memory file initialized during documentation baseline (structure v{harness-version} — read from `.claude/harness.json` / `docs/structure.md` frontmatter; never hardcode a literal version).
-```

package/data/harnesses/apollo/skills/documentation/templates/migration-runbook.md

@@ -1,34 +0,0 @@
-# Migration Runbook (docs/history/migrations/YYYY-MM-DD-{slug}.md)
-
-Record. Use for: a **one-shot** migration, upgrade, or data operation — authored before execution, executed once, then outcome-stamped and frozen. Supporting scripts live beside it in a same-named folder when needed (`YYYY-MM-DD-{slug}/`).
-
-Required: **Goal**, **Steps**, **Verification**, and — after execution — the **Outcome** stamp. Optional: Preconditions, Rollback.
-
-```
-# Migration: {Title}
-
-**Goal:** What this migration accomplishes and why it runs now, one or two lines.
-**Executes against:** {environment / database / system}
-
-## Preconditions
-
-- Backups taken, feature flags set, access confirmed — exact checks
-
-## Steps
-
-1. One action per step, exact command in a code block
-2. Note expected output where it disambiguates success from failure
-
-## Verification
-
-- The observable end state that confirms success — exact check commands
-
-## Rollback
-
-- How to undo, and the point of no return
-
-## Outcome
-
-<!-- Stamped once, immediately after execution; the file freezes with it. -->
-**Executed:** YYYY-MM-DD — {result: clean | issues encountered + how resolved | aborted + why}
-```

package/data/harnesses/apollo/skills/documentation/templates/non-goals.md

@@ -1,11 +0,0 @@
-# Non-Goals (docs/architecture/non-goals.md)
-
-Truth document. Use for: what the system deliberately does **not** do. A non-goal is a decision, not an omission — each entry carries the why and what would reopen it. Readers (and agents) use this to stop re-proposing settled exclusions.
-
-```
-# Non-Goals
-
-Things this system deliberately does not do. Each is a decision — don't re-propose one without new information of the kind its "revisit if" names.
-
-- **{Non-goal}** — {why it's excluded}. Revisit if: {the trigger that would reopen it}.
-```

package/data/harnesses/apollo/skills/documentation/templates/operations-procedure.md

@@ -1,36 +0,0 @@
-# Operations Procedure (docs/operations/{procedure}.md)
-
-Truth document. Use for: any **recurring** procedure — setup, development, deployment, maintenance. A procedure is consulted mid-task, not read: exact commands, copy-paste runnable, no narrative. Updated in place whenever the workflow changes.
-
-A **one-shot** procedure (a migration, an upgrade, an incident response executed once) is not an operations doc — it is a **Migration Runbook** (record, below). The test: will someone run this again next month? Yes → operations. No → runbook.
-
-Required: **Goal**, **Steps**, **Verification**. Optional: Preconditions, Troubleshooting, Rollback — include only when they carry real content.
-
-If a procedure is a deterministic command list run frequently, script it and have the doc point at the script — a doc should carry judgment (when, why, what to check), not replace automation.
-
-```
-# {Procedure Name}
-
-**Goal:** What this procedure accomplishes, one line.
-
-## Preconditions
-
-- Access, tools, or state required before starting — exact versions, env vars, credentials location
-
-## Steps
-
-1. One action per step, exact command in a code block
-2. Note expected output where it disambiguates success from failure
-
-## Verification
-
-- The observable end state that confirms it worked — exact check commands, not "it should work now"
-
-## Troubleshooting
-
-- Symptom → cause → fix (append entries as failures are root-caused)
-
-## Rollback
-
-- How to undo, and when undo stops being possible
-```

package/data/harnesses/apollo/skills/documentation/templates/plan.md

@@ -1,88 +0,0 @@
-# Plan (docs/history/plans/YYYY-MM-DD-feature-name.md)
-
-Record. Use for: every implementation plan. Plans are created here directly with `Status: Draft`; after approval the plan gates (`boundary`, then `testing` plan-gate mode) run against the still-`Draft` file, the status flips to `Status: In Progress` at the first implementation step, and the file freezes at `Status: Complete` or `Status: Abandoned`. Once frozen, never edit — write a new dated plan if scope changes. The plan records the journey; the truth it implemented lives on in the feature doc and any AD it touched.
-
-The `boundary` skill parses the **Proposed Changes** sections to check boundary impact before execution, and the `testing` skill (plan-gate mode) writes a **Test Obligations** section into the plan at the same gate. Keep that structure stable — section headings and bullet shape are load-bearing for the parsers, and the Test Obligations table is the ledger the verification gate discharges before the plan may reach `Status: Complete`.
-
-**Doc Obligations is the one ledger the plan's author writes.** Deriving tests from behavior is judgment, which is why `testing` owns that section and it is marked never-hand-author; resolving Proposed Changes' file paths to the feature docs that own them is a **lookup** against the ownership index already injected at session start. Different work, different rule — fill it yourself, while the touch list is fresh.
-
-The **`Gates:`** line is machine-read: the compliance hook greps exactly the forms below, and implementation edits are blocked while a segment reads `pending`. Each gate skill rewrites only its own segment when it runs — `boundary` to `Boundary: passed YYYY-MM-DD` or `Boundary: blocked YYYY-MM-DD`; `testing` (plan-gate mode) to `Test-plan: written YYYY-MM-DD (N rows)` — the segment label stays `Test-plan`, greppable. The author writes `Docs: mapped YYYY-MM-DD (N docs)` when the Doc Obligations table is filled. Never hand-edit the line to skip a gate.
-
-```
-# {Feature Name}
-
-**Status:** Draft | In Progress | Complete | Abandoned
-**Gates:** Boundary: pending · Test-plan: pending · Docs: pending
-**Spec:** [docs/features/{feature}.md](../../features/{feature}.md)   <!-- one line per feature doc this plan implements against; a plan spanning three features names three -->
-**Started:** YYYY-MM-DD
-**Completed:** YYYY-MM-DD   <!-- fill when status flips to Complete -->
-
-## Background
-
-Why this work is happening *now*. Link to the spec for *what* we're building; this section is the motivation and the trigger. One paragraph.
-
-## Proposed Changes
-
-### New Files
-
-- `src/path/new-file.js` — purpose
-
-### Modified Files
-
-- `src/path/existing.js` — what changes and why
-
-### New Entities / State
-
-- `entities.foo` — new Redux slice / DB table / persisted shape
-- Persisted state addition: `state.bar.baz` (default `null` for existing users on rehydrate)
-
-### API Changes
-
-- `POST /api/foo` — new route, request `{...}`, response `{status, data}`
-- `PUT /api/bar` — request shape changes; see Migration
-
-### Cross-Module Contracts Affected
-
-- List which cross-cutting contracts this plan affects (db schema, wire envelope, auth, events, env/config, …)
-- "None" is a valid answer and means the `boundary` check will pass cleanly
-
-## Doc Obligations
-
-<!-- One row per feature doc whose `owns:` globs intersect the Proposed Changes above — resolve
-     them against the injected ownership index. Hand-authored: this is a lookup, not research.
-     Amendable while the plan is open; discharged at Completion. -->
-
-| Doc | Claim that changes | `owns:` still accurate? |
-| --- | --- | --- |
-| `docs/features/{feature}.md` | what it says today that this plan makes false | yes / no — new paths to add |
-
-**"None" is valid** — a plan touching only unowned paths owes no doc update, and says so explicitly. It is not a free pass: `boundary` builds its own touch list from the same Proposed Changes and reports docs this table missed.
-
-## Implementation Steps
-
-1. Concrete, ordered, testable
-2. Each step ends with something verifiable
-3. ...
-
-## Test Obligations
-
-<!-- Written by the `testing` skill (plan-gate mode) at the plan gate (after `boundary`). One row per
-     promised behavior: layer · target file · oracle · fixtures. Amendable while the
-     plan is open; discharged at the verification gate. Do not hand-author. -->
-
-## Done Criteria
-
-- [ ] Implementation complete
-- [ ] Verification gate passed — every Test Obligations row discharged (satisfied / owes nothing / blocked → backlog), gate run date and results noted here
-- [ ] Every Doc Obligations row discharged — **updated** / **owes nothing** (with the reason) / **blocked** (→ backlog item, so the debt outlives the frozen plan)
-- [ ] Changelog entry created in `docs/history/changelog/`, carrying the gate's results
-- [ ] Plan marked `Status: Complete`, **Completed:** date filled
-
-## Open Questions
-
-- Question — who decides, by when
-
-## Risks
-
-- Risk — likelihood / impact / mitigation
-```

package/data/harnesses/apollo/skills/documentation/templates/protected-files.md

@@ -1,37 +0,0 @@
-# Protected Files
-
-Truth document. Use for: documenting critical files that need approval before modification.
-
-This doc answers *what is protected and why breaking it hurts* — nothing more. Don't duplicate function-level detail here (signatures, inputs/outputs): it drifts from both the code and the owning feature doc. The owning feature doc is the canonical reference for how the code works; link to it.
-
-```
-# Protected Files
-
-Critical files requiring approval before modification.
-
-## File List
-
-# Category 1 - Description
-path/to/critical/file1.js
-path/to/critical/file2.js
-
-# Category 2 - Description
-path/to/another/file.js
-
-## Risk Summary
-
-| Category   | Risk if Broken  |
-|------------|-----------------|
-| Category 1 | Specific impact |
-| Category 2 | Specific impact |
-
-## Why Protected
-
-### Category 1: [Name]
-
-**Purpose:** What these files do, one or two lines
-**Owning doc:** [docs/features/{feature}.md] — canonical reference for how this code works
-**Invariants:**
-- The behavior that must not break, stated as a constraint (not a function tour)
-- Important point 2
-```

package/data/harnesses/apollo/skills/documentation/templates/root-readme.md

@@ -1,104 +0,0 @@
-# Project Root README
-
-Truth document. Use for: the human-facing entry point at the repository root (`/README.md`) — what visitors and new contributors land on. Distinct from `docs/README.md` (the agent/doc index — see **docs/README.md (Documentation Root)** above). The two coexist; don't merge them.
-
-### Strategy
-
-The root README answers, in order:
-
-1. **What is this?** — one to two sentences, no marketing claims
-2. **What do I get if I install it?** — capability families
-3. **What's it built on?** — terse stack list with versions
-4. **How do I run it?** — the three or four scripts that matter
-5. **How is it laid out?** — directory tree, one-liner per significant folder
-6. **How do I extend it?** — numbered contribution checklist
-7. **What state is it in?** — pre-publish, beta, stable, internal
-
-Skip any section that doesn't apply. Don't pad to fill the template.
-
-### Writing rules
-
-- **Sentence-case headings.** "Getting started", not "Getting Started".
-- **Concrete over abstract.** Real versions, real paths, real commands. No "leverages cutting-edge…".
-- **The tagline answers "what is this?"** — not "why is it great?". Two sentences max.
-- **Tables for enumeration** (routes, commands, endpoints). **Bullets for families and categories.**
-- **Directory tree as a code block**, not a nested markdown list.
-- **Numbered checklist** for "how to add a thing" — readers should be able to follow it top-to-bottom without re-reading.
-- **Point to `docs/` for depth.** The root README links into deep docs; it doesn't host them.
-- **Detect the package manager from the lockfile** (`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, otherwise npm) and write commands accordingly. Don't hardcode `npm` if the repo uses pnpm.
-
-### Template
-
-```markdown
-# {package-name}
-
-{One- to two-sentence positioning. What it is and what scope it covers. No superlatives, no value claims.}
-
-## What's in the box
-
-- **{Family 1}** — {what's in it; a few specific items, comma-listed.}
-- **{Family 2}** — {what's in it.}
-- **{Family 3}** — {what's in it.}
-
-The full surface lives in [`{path/to/public-index}`]({path/to/public-index}). ← optional pointer for libraries
-
-## Stack
-
-- {Framework} {version} · {Language} {version}
-- {Build tool} {version}
-- {Other load-bearing deps}
-
-## Getting started
-
-\`\`\`bash
-{pm} install
-{pm} run dev        # what it does (port, URL)
-{pm} run build      # what it does
-{pm} run preview    # what it does (omit if not applicable)
-\`\`\`
-
-{Optional one-liner about first-run behavior — e.g., "Dev server lands on /playground."}
-
-## {Runtime entry point} ← optional; e.g., "The playground", "CLI", "API endpoints"
-
-{Brief description of the dev/runtime surface.}
-
-| {Thing}              | {What it shows / does} |
-| -------------------- | ---------------------- |
-| `{route or command}` | {description}          |
-
-## Layout
-
-\`\`\`
-src/
-├── {entry-file}        # {purpose}
-├── {folder}/           # {purpose}
-│   └── ...
-└── {folder}/           # {purpose}
-\`\`\`
-
-## Adding a {primary unit}
-
-1. {Drop the source under the right family/folder.}
-2. {Re-export from the public surface.}
-3. {Wire into the playground / example app / test harness so reviewers can see it render.}
-4. {Document any divergence from upstream in `docs/{...}`.}
-
-## Styling ← optional; replace with whichever cross-cutting concern matters most
-
-{Configuration notes that affect every consumer — design tokens, conventions, opt-outs.}
-
-## Status
-
-{Pre-publish, beta, stable, internal-only. State the stability tier per surface — which APIs are contracts and which are experimental — so readers know what can be relied on.}
-
-## License
-
-{License name — scope. e.g., "UNLICENSED — internal use only", "MIT".}
-```
-
-### Baseline scaffolding behavior
-
-The baseline audit **does** scaffold the project root README when missing. The risk this template guards against — template-shaped placeholders that look abandoned — is mitigated by the writing rules above: fill every section with concrete details from the repo (real package manager from the lockfile, real scripts, real layout, real status). Skip sections that genuinely don't apply rather than leaving stubs.
-
-**Never overwrite an existing root README** during a baseline. If one is present — even sparse or outdated — leave it untouched. Treat updates to a pre-existing root README as a separate, explicit request.

package/data/harnesses/apollo/skills/documentation/templates/security-overview.md

@@ -1,27 +0,0 @@
-# Security Overview (docs/architecture/security.md)
-
-Truth document. Use for: the single place the system's security posture is stated — assets, trust boundaries, controls, and accepted risks. Controls link to the code that implements them; this doc asserts, the code proves.
-
-Required: **Trust boundaries**, **Controls**. Optional: Assets, Accepted risks.
-
-```
-# Security Overview
-
-## Assets
-
-- {What's worth protecting — data classes, credentials, tenant isolation}
-
-## Trust boundaries
-
-- {Boundary} — {what crosses it, and what checks the crossing} 
-
-## Controls
-
-| Control | Protects against | Implemented in |
-| ------- | ---------------- | -------------- |
-| {control} | {threat} | `{file/module}` |
-
-## Accepted risks
-
-- {Risk knowingly carried} — accepted because {reason}; owner: {who}. Revisit if: {trigger}.
-```

package/data/harnesses/apollo/skills/documentation/templates/structure.md

@@ -1,65 +0,0 @@
-# docs/structure.md (Authority Map)
-
-Truth document. Use for: defining which folder owns which topic and how docs are maintained.
-
-```
----
-harness-version: 1.0.0
----
-
-# Documentation Structure
-
-> This file is the entry point for understanding the docs folder.
-> `harness-version` above is the repo's single baseline/version sentinel — the `maintenance` agent (baseline mode) owns it and stamps the installed harness version (semver) on every reconcile.
-
-## Authority Map
-
-Each topic has one canonical location. Read from here, not from plans or changelogs.
-
-| Topic | Authority | Key Files |
-| ----- | --------- | --------- |
-| Code-path ownership (path → doc + module) | feature `owns:` frontmatter | the generated ownership index |
-| System overview | `docs/architecture/` | system-design.md |
-| Steering (domain model, glossary, non-goals) | `docs/architecture/` | domain-model.md, glossary.md, non-goals.md |
-| Architecture decisions (ADs) | `docs/architecture/decisions/` | AD-NNN-*.md |
-| API surface | `docs/architecture/` | api.md |
-| Security | `docs/architecture/` | security.md |
-| Feature behavior | `docs/features/` | {key files} |
-| Setup & development | `docs/operations/` | {key files} |
-| Environment / config surface | `docs/operations/` | environment.md |
-| Testing strategy | `docs/tests/` | strategy.md |
-| Historical plans | `docs/history/plans/` | YYYY-MM-DD-name.md |
-| Change records | `docs/history/changelog/` | `YYYY-MM-DD-{three-words}.md` — one per unit of work, written at commit time |
-| Migration runbooks | `docs/history/migrations/` | YYYY-MM-DD-name.md |
-| Deep-research artifacts | `docs/history/research/{topic}/` | README.md + findings.md + sources.md |
-| Brainstorm design records | `docs/research/{topic}-brainstorm/` (active; legacy `-brainstorming/`) → `docs/history/brainstorms/{topic}/` (harvested; user deletes or commits) | thesis.md + forks.md + ledger.md + state.md |
-| Backlog | `docs/history/` | backlog.md |
-
-## The Two Natures
-
-Every doc is a **truth document** (states current absolutes, topic-named, updated in place) or a **record** (dated account of activity, frozen or append-only). `architecture/`, `features/`, `operations/`, `tests/` hold truth; `history/`, `research/`, `memory/` hold records.
-
-- Truth documents are rewritten in place when reality changes — the change-story goes to a changelog entry, never into the truth doc's body.
-- Records freeze: plans at `Complete`/`Abandoned`, changelog entries and migration runbooks once written/executed. A scope change is a new dated record that links back.
-- Feature docs are the living reference for implemented features; an AD is the living truth for one decision subject, with its dated journey confined to its Decision Changelog tail.
-
-## Folder Rules
-
-- `docs/features/`: Living reference for implemented features. Each feature doc **carries** the `owns:` / `module:` / `keywords:` / `status:` frontmatter — `owns:` declares the code-path globs it owns (the only ownership key), `module:` is an optional bounded-context label, `keywords:` are discovery terms, `status:` is `active`/`draft`/`deprecated`. The SessionStart hook unions every feature's `owns:` globs into the injected ownership index.
-- `docs/architecture/`: The truth layer for system-wide shape: overview, domain model, glossary, non-goals, API surface, security, and `decisions/` (ADs — one per subject, updated in place, journey in each AD's Decision Changelog). Update when cross-cutting reality changes.
-- `docs/operations/`: How-to procedures for setup, development, and deployment, plus the environment registry. Update when workflows change. One-shot migrations do NOT live here — they are records (`docs/history/migrations/`).
-- `docs/tests/`: Testing strategy and test docs. Present when the repo has a test posture worth documenting.
-- `docs/history/plans/`: Records. Must have `Status:` field. Never modify after completion.
-- `docs/history/changelog/`: Records. One entry per unit of work (`YYYY-MM-DD-{three-words}.md`), written by whoever does the work and frozen inside the commit it describes. Entries carry the refinement context a diff cannot show — the ask in the user's words, iterations and rejections, skill survived/overridden verdicts, discoveries, pins. Format is the `documentation` skill's `templates/changelog-entry.md`; trigger and lifecycle are the `changelog` rule; distillation is the `retro` agent. Immutability begins at commit — a draft in the working tree is mutable until then, never after. Every entry appends a row to `docs/history/CHANGELOG.md`.
-- `docs/history/migrations/`: Records. One-shot migration/upgrade runbooks — authored before execution, outcome-stamped and frozen after.
-- `docs/history/research/{topic}/`: Deep-research artifacts — the dumped output of a research pass, one folder per topic (conventionally `README.md` synthesis + `findings.md` verified claims & citations + `sources.md`). A point-in-time, cited record — **not** a living authority doc: it owns no code (no `owns:` frontmatter) and is never edited to "stay current." A spec/plan links to it for grounding; a new question gets a new topic folder.
-- `docs/research/{topic}-brainstorm/` → `docs/history/brainstorms/{topic}/`: Brainstorm design records — the Brainstorming-Mode session for a topic (working surface `thesis.md` + `forks.md` + `ledger.md` + `state.md` + `basis/` + `fragments/`, plus an untracked `ops/` capture layer deleted at stop), written by the `brainstorm` skill and its twin agent. An active session lives under `docs/research/` (legacy folders carry the older `-brainstorming/` suffix); on a **passed harvest** it **moves** to `docs/history/brainstorms/` — the completion marker — and the **user decides whether the moved folder is deleted or committed** as provenance. Each of the two folders carries a `Readme.md` index (the skill reads it at start instead of scanning). Author-created (never scaffolded empty), one folder per design conversation. Owns no code (no `owns:` frontmatter); the harvest routes its conclusions into `architecture/`/`features/`/`history/`. (Distinct from `docs/history/research/{topic}/` above — that is a frozen deep-research record, not a brainstorm session.)
-- `docs/history/backlog.md`: Tracked work items. Append new items under appropriate priority.
-
-## Health Log
-
-<!-- Updated by maintenance agent — the sanctioned dated tail in this truth doc (SKILL.md § The Two Natures names the two bridges) -->
-| Date | Review Summary |
-| ---- | -------------- |
-| {today} | Initial baseline — v{harness-version} structure established |
-```

package/data/harnesses/apollo/skills/documentation/templates/system-overview.md

@@ -1,32 +0,0 @@
-# System Overview (docs/architecture/system-design.md)
-
-Truth document. Use for: the bird's-eye view — what the system is, its subsystems, and how they connect. The first doc a new reader opens after the README; austere and short (two screens max). Depth lives in feature docs — this doc maps, it doesn't explain.
-
-Required: **What this is**, **Subsystem map**. Optional: Key flows, Where the truth lives.
-
-```
-# System Overview
-
-## What this is
-
-{Two or three sentences: what the system does, for whom, in what environment it runs.}
-
-## Subsystem map
-
-┌──────────┐     ┌──────────┐     ┌──────────┐
-│ Frontend │────▶│   API    │────▶│    DB    │
-└──────────┘     └──────────┘     └──────────┘
-{One box per subsystem; label the arrows with the contract that crosses them.}
-
-- **{Subsystem}** — one line: what it owns. → [owning doc](../features/{feature}.md)
-
-## Key flows
-
-{At most two or three ASCII flow diagrams for the flows everything else hangs off — request lifecycle, auth, the core domain operation.}
-
-## Where the truth lives
-
-| Area | Canonical doc |
-| ---- | ------------- |
-| {area} | [{doc}](path) |
-```

package/data/harnesses/apollo/skills/documentation/templates/testing-strategy.md

@@ -1,29 +0,0 @@
-# Testing Strategy (docs/tests/strategy.md)
-
-Truth document. Use for: the repo's test posture — what is tested at which level, how to run it, and what is deliberately untested. The framework choices come from the harness testing rule; this doc records how *this repo* applies them.
-
-Required: **Levels**, **Running**. Optional: Deliberately untested, Adding a test.
-
-```
-# Testing Strategy
-
-## Levels
-
-| Layer | Runner | Lives in | Covers |
-| ----- | ------ | -------- | ------ |
-| Unit / integration | {runner} | `tests/` | {what} |
-| E2E | {runner} | `e2e/` | {what} |
-
-## Running
-
-- `{pm} test` — the whole unit suite (CI gate)
-- `{pm} run test:e2e` — {when to run}
-
-## Deliberately untested
-
-- {Area} — {why, and what verifies it instead (typecheck, boot check, manual journey)}
-
-## Adding a test
-
-1. {Where the file goes, what it's named, where fixtures live}
-```