hstack 0.7.1 → 0.17.0

package/template/templates/plan.md

@@ -1,49 +0,0 @@
----
-id: <parent-change-id>-plan
-type: plan
-status: draft                          # draft | ready | in-progress | completed | archived
-owner: <git-handle>
-parent-change: <change-spec-id>
-steps-completed: []                    # populated by `implementer` as phases finish
-blocked-on: null                       # phase id when an interactive blocker stops progress
-oversized-plan-justification: null     # required when phase count > 12
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Phase Overview
-
-_Table of phases. Three columns max._
-
-| step-id | summary | depends-on |
-| --- | --- | --- |
-| phase-1- |  | none |
-
-## Per-Phase Detail
-
-_One subsection per phase. 4–8 phases typical. >12 requires `oversized-plan-justification` in frontmatter._
-
-### phase-1-
-
-**Purpose.** _One sentence._
-
-**Files Touched.** _Subset of `change-spec.in-scope`. Bullets._
-
--
-
-**Test Strategy.** _Pointer to the test-plan section(s) this phase satisfies. Format: `test-plan §<section> — <one-line summary>`. The phase lands the tests named in the referenced section; do not restate or invent tests here. If this phase's work is exclusively non-test (e.g., a migration whose tests live in a later phase), state that explicitly and name the downstream phase that closes the loop._
-
-**Risk.** _One sentence on what could go wrong locally._
-
-**Verifier Expectations.** _What `verifier` must observe to mark this phase passed. References both this plan's Test Strategy and the test-plan sections the phase satisfies._
-
-## Cross-Phase Risks
-
-_Challenge prompt: what could go wrong across phase boundaries that no single phase catches? 1–3 bullets._
-
--
-
-## Rollback
-
-_What to do if a partial rollout in production breaks something. 2–4 sentences._

package/template/templates/product-brief.md

@@ -1,56 +0,0 @@
----
-id: product-brief
-type: product-brief
-status: draft                          # draft | current | needs-refresh | archived
-owner: <git-handle>
-technique-used: <brainstorm | forcing-questions | project-brief>
-derived-from: []                       # always empty — product-brief is Phase 1, no upstream
-downstream: [vision, mvp-scope, personas, glossary]
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Underlying Pain
-
-_What the user actually struggles with on a Tuesday morning, in concrete terms. Not "users want X" — "this specific person spends 20 minutes doing Y and misses Z." One paragraph, 4–8 sentences. The forcing-prompt reframes should have moved this away from the founder's first articulation; the result lands here._
-
-## Target User
-
-_A named, specific user (not "users", not "customers") with a workday vignette. Includes role, company-size band, tools they use today, the workflow this product enters. If multiple personas matter for v1, name them all — but each must pass the concreteness floor._
-
-## Value Proposition
-
-_What this product delivers to the named user, in their language. One paragraph. Distinct from features — this is the outcome they buy._
-
-## Smallest Useful Wedge
-
-_The minimum shippable surface that delivers real value to the named user. Forcing-prompt answer: "Would the named user still pay for this if you shipped only the wedge and nothing else?" Yes required; if no, the wedge is too large or the user is wrong._
-
-## Success Criteria
-
-_Concrete, measurable, time-bound. "Maya saves 10 minutes per QBR prep within 4 weeks of activation" not "users love it." At least one criterion; more is better._
-
-## Explicitly NOT
-
-_Two-bullet minimum. The boundaries of the product. What this is NOT, what it does NOT do, what populations it does NOT serve. Required, never optional — over-broad scoping is the #1 product failure mode._
-
--
--
-
-## Open Risks
-
-_The things that could make this product fail. The forcing-prompt "What would you have to believe to be wrong about this?" answer lands here. At least one risk; more is better._
-
-## Forcing-Prompt Answers
-
-_Evidence that the three required reframes ran. Logged inline as confirmation the probes were not skipped._
-
-**Who specifically pays for this?**
-_The named user / buyer plus the rationale ("Director of CS, because retention is their KPI")._
-
-**What's the smallest useful wedge?**
-_The wedge plus the rationale ("Change-awareness alone, because the rest of the workflow is downstream of it")._
-
-**What would you have to believe to be wrong about this?**
-_The belief plus the falsifiability angle ("That CS reps will trust LLM-generated summaries — wrong if they require human-curated context")._

package/template/templates/security-review.md

@@ -1,63 +0,0 @@
----
-id: <parent-change-id>-security-review
-type: security-review
-status: draft                          # draft | in-progress | passed | concerns-acknowledged | failed | superseded
-owner: <git-handle>
-parent-change: <change-spec-id>
-scoring-mode: llm-scored               # v1; v2 introduces 'executed'
-scores:
-  data-at-rest: not-applicable         # pass | concerns | fail | not-applicable
-  data-in-transit: not-applicable
-  authn: not-applicable
-  authz-rls: not-applicable
-  tenant-isolation: not-applicable
-  input-validation: not-applicable
-  output-encoding: not-applicable
-  secrets-handling: not-applicable
-  agent-prompt-injection: not-applicable
-  audit-logging: not-applicable
-concerns-acknowledged-by: null         # handle required when any score is `concerns`
-threat-model-delta-required: false     # true when surfaces touches agent | auth | api | db
-challenge-prompts-answered: 0          # must equal 3 to pass
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Surfaces Touched
-
-_Pointer to change-spec `surfaces`. One sentence per surface._
-
-## Hardening Items Scored
-
-_For every applicable checklist item, a one-paragraph rationale for the score. Bias toward CONCERNS rather than PASS when evidence is thin._
-
-### data-at-rest
-
-### data-in-transit
-
-### authz-rls
-
-### tenant-isolation
-
-### input-validation
-
-### audit-logging
-
-## Threat-Model Delta
-
-_Required when `threat-model-delta-required: true`. One paragraph delta against the current threat-model.md. Refuse to score until this is non-empty when surfaces require it._
-
-## Challenge Prompts
-
-_All three required. Each answer must be at least one paragraph._
-
-### (a) What attack vector did the In-Scope diff create that is NOT covered by the hardening checklist? If none, justify.
-
-### (b) Which tenant_isolation guarantee does this change depend on? Cite the line of code that enforces it.
-
-### (c) What part of this change would behave incorrectly under a malicious payload that the test suite does not cover?
-
-## Open Concerns
-
-_When any score is `concerns`: what acknowledgement is required and by whom. Ack must be human-confirmed by `owner` before status: concerns-acknowledged._

package/template/templates/telemetry-sidecar.md

@@ -1,184 +0,0 @@
-# Telemetry sidecar — schema and discipline
-
-This document describes the JSON sidecar files three hstack Skills emit alongside their canonical artifact writes, to make per-change telemetry attribution cheap. Sidecars are **derivative** of git + frontmatter — re-runnable from source, never authoritative. The kernel's "no parallel tracker" rule is preserved by this derivative property.
-
-## Where sidecars live
-
-```
-hstack/specs/changes/<change-id>/.telemetry/
-  test-plan.json                # one per test-plan terminal status
-  implement-<phase-id>.json     # one per implement phase
-  verify.json                   # one per verify pass
-  adversarial-review.json       # one per adversarial-review terminal status
-  finalize.json                 # one per ship
-```
-
-The `.telemetry/` directory is **git-ignored** at the consuming-repo level. Sidecars are transient; the canonical truth lives in the artifact frontmatter and git history.
-
-## When sidecars are written
-
-| Skill | Trigger | File |
-| --- | --- | --- |
-| `hstack-test-plan` | At the test-plan terminal-status commit (`passed` or `concerns-acknowledged`) | `test-plan.json` |
-| `hstack-implement` | At each phase-completion auto-commit (the same `git add && git commit` that lands `plan.steps-completed`) | `implement-<phase-id>.json` |
-| `hstack-verify` | At the change-spec advance commit when `verification.md` lands at `status: passed` (per ADR-0002); on `ran`/`failed`, piggybacks on the verification status commit | `verify.json` |
-| `hstack-adversarial-review` | At the change-spec advance commit when `adversarial-review.md` lands at `findings-resolved` (per ADR-0002 follow-up); on `findings-open`/`in-progress`, piggybacks on the transition commit | `adversarial-review.json` |
-| `hstack-finalize` | At the change-spec advance commit when status moves `ready-to-ship → shipped` | `finalize.json` |
-
-The other 22 Skills do **not** emit sidecars in v1. Their data is reconstructible from git + frontmatter + transcripts; the five emissions above target the highest-signal events across the change lifecycle: test discipline up front (`test-plan`), per-phase scope-locked execution (`implement`), promised-vs-observed (`verify`), gate-firing critique (`adversarial-review`), lifecycle close (`finalize`).
-
-## Schema — `test-plan.json`
-
-```json
-{
-  "schema_version": 1,
-  "skill": "hstack-test-plan",
-  "change_id": "2026-05-billing-overage-warning",
-  "completed_at": "2026-05-22T11:14:00Z",
-  "status": "passed",
-  "coverage_layers": {"unit": "addressed", "integration": "addressed", "e2e": "not-applicable"},
-  "tenant_isolation_tests_count": 0,
-  "tenant_isolation_required": false,
-  "performance_budgets_required": false,
-  "performance_budgets_count": 0,
-  "challenge_prompts_answered": 3,
-  "invariants_mapped_count": 4,
-  "invariants_declared_count": 4,
-  "edge_cases_count": 5,
-  "test_files_named_count": 7,
-  "fixture_strategy_declared": true,
-  "halt_reasons": []
-}
-```
-
-Field rules:
-
-- `tenant_isolation_tests_count` paired with `tenant_isolation_required` is the rubber-stamp tell. `required: true` with `count: 0` at terminal status is a TS-03 contract violation that should have halted the Skill — its presence in a `passed` sidecar is a high-severity signal.
-- `challenge_prompts_answered` must be exactly `3` for `passed`. Lower values at `passed` indicate either a validator gap or a Skill bypass.
-- `invariants_mapped_count` lower than `invariants_declared_count` at `passed` is a TS-06 violation. Same signal-handling as above.
-
-## Schema — `implement-<phase-id>.json`
-
-```json
-{
-  "schema_version": 1,
-  "skill": "hstack-implement",
-  "change_id": "2026-05-billing-overage-warning",
-  "phase_id": "phase-3-component",
-  "started_at": "2026-05-22T14:00:00Z",
-  "completed_at": "2026-05-22T14:18:42Z",
-  "files_touched_count": 4,
-  "tests_written_count": 2,
-  "scope_amendment_emitted": false,
-  "halt_reasons": [],
-  "test_immutability_authorizations": []
-}
-```
-
-Field rules:
-
-- `started_at`, `completed_at` — ISO-8601. The implementer records them from session timestamps.
-- `files_touched_count` — count of distinct files modified by the phase's commit. Computed mechanically; not a judgment.
-- `tests_written_count` — count of test files newly created in the phase (kernel test-immutability rule allows new tests without authorization).
-- `scope_amendment_emitted` — `true` only when the implementer halted and surfaced a scope-amendment request during this phase.
-- `halt_reasons` — array of enum values from the kernel halt sentinel (see CLAUDE.md § Halt sentinel).
-- `test_immutability_authorizations` — array of canonical authorization phrases echoed during this phase (e.g., `"Ok to change test foo"`).
-
-## Schema — `verify.json`
-
-```json
-{
-  "schema_version": 1,
-  "skill": "hstack-verify",
-  "change_id": "2026-05-billing-overage-warning",
-  "ran_at": "2026-05-22T15:32:00Z",
-  "test_suite_runtime_s": 187.4,
-  "phase_coverage": {"phase-1-types": "pass", "phase-2-component": "pass"},
-  "test_plan_coverage": {
-    "edge-cases": "all-observed",
-    "tenant-isolation": "not-applicable",
-    "performance-budgets": "not-applicable"
-  },
-  "discrepancies_count": 0,
-  "status": "passed"
-}
-```
-
-Field rules:
-
-- `test_suite_runtime_s` — float seconds. Wall-clock elapsed across all canonical commands.
-- `phase_coverage`, `test_plan_coverage` — mirror `verification.md` frontmatter for cheap downstream parsing. When verification fails, the sidecar still lands at the corresponding `ran` or `failed` status; the canonical artifact is the source of truth for any discrepancy.
-- `discrepancies_count` — count of bullet points under `verification.md § Discrepancies`. A non-zero value should always pair with a non-empty Discrepancies section in the canonical artifact.
-
-## Schema — `adversarial-review.json`
-
-```json
-{
-  "schema_version": 1,
-  "skill": "hstack-adversarial-review",
-  "change_id": "2026-05-billing-overage-warning",
-  "reviewed_at": "2026-05-22T16:42:00Z",
-  "findings_floor": 5,
-  "findings_count": 6,
-  "findings_fewer_than_floor": false,
-  "category_counts": {
-    "security": 1,
-    "scope-drift": 0,
-    "invariant-breach": 1,
-    "spec-compliance": 2,
-    "data-integrity": 1,
-    "code-quality": 1
-  },
-  "severity_counts": {"critical": 0, "high": 1, "medium": 3, "low": 2},
-  "resolution_mix": {"commit": 4, "tech-debt": 1, "justified-in-prose": 1},
-  "fresh_session_attestation": "session abc-123; opened 2026-05-22T16:40Z; no implementer transcripts loaded",
-  "halt_reasons": []
-}
-```
-
-Field rules:
-
-- `findings_floor` is `3` by default, `5` when `change-spec.area` is in `{agent, auth, billing}` per AR-06.
-- `findings_count` < `findings_floor` is permitted only when `findings_fewer_than_floor: true` (with a defended justification in the canonical artifact's Findings Floor Justification section). Aggregating across changes: a rising `findings_fewer_than_floor: true` rate means either the floors are wrong or the reviewer is gaming the escape hatch.
-- `category_counts` clustering — e.g., 5 of 5 findings in `code-quality` — is the quota-gaming smell the kernel's "spread findings across categories" guidance is designed to detect. The telemetry layer surfaces it via OE-7.
-- `severity_counts.high + critical` paired with `resolution_mix.justified-in-prose > 0` is a high-severity-in-prose smell flagged by QO-2. The Skill's stop condition should have caught it before terminal status; sidecar presence indicates a bypass.
-
-## Schema — `finalize.json`
-
-```json
-{
-  "schema_version": 1,
-  "skill": "hstack-finalize",
-  "change_id": "2026-05-billing-overage-warning",
-  "shipped_at": "2026-05-23T10:14:00Z",
-  "merge_commit_sha": "abc1234567890",
-  "change_duration_days": 4,
-  "tds_resolved": ["TD-0042-overage-banner-tailwind-class"]
-}
-```
-
-Field rules:
-
-- `merge_commit_sha` — full SHA of the merge commit on the default branch.
-- `change_duration_days` — integer days from `change-spec.created` to the merge commit's author date.
-- `tds_resolved` — list of TD ids; mirrors `change-spec.resolves-tech-debt`. Empty array on changes that resolve no debt.
-
-## Discipline preserved
-
-Per the kernel § Mechanical operations § Discipline preserved:
-
-- **Atomic with the canonical commit.** Each sidecar is written and `git add`-ed in the same commit as the canonical artifact write. No separate commit. The sidecar piggybacks on a commit that was happening anyway — zero new LLM turns, zero new confirmation gates.
-- **Idempotency.** Re-running a Skill on a phase that already landed produces a no-op on the sidecar (file already present, content unchanged aside from `schema_version` bumps if any).
-- **Derivative property.** Every value in every sidecar is reconstructible from git + frontmatter + transcripts. The sidecar is a cache, not a source. Deleting a sidecar is harmless — the next `/hstack:telemetry` run will compute the same metrics from the slower path.
-- **Schema versioning.** `schema_version: 1` in v1. Bumping to `2` requires either a backward-compatible additive change (new optional field) or a migration in `scripts/telemetry/parsers/`.
-
-## What sidecars are NOT
-
-- Not authoritative. The artifact frontmatter and git history are. If a sidecar disagrees with the artifact, the artifact wins.
-- Not an audit trail. The kernel reserves "agent-ledger" naming for the v2 substrate when it ships with cryptographic guarantees.
-- Not blocking. A sidecar write failure is logged but does not block the canonical commit.
-- Not a parallel tracker. The kernel forbids parallel trackers; sidecars survive that rule only because they are derivative.
-
-## Adding sidecar emission to a new Skill
-
-The v1 emission list is fixed at five Skills (`test-plan`, `implement`, `verify`, `adversarial-review`, `finalize`). Adding a sixth is a follow-up change-spec, not a unilateral Skill edit. The cost-benefit threshold: a Skill is sidecar-eligible when its terminal event is per-change (not per-session), the data the sidecar would carry is non-trivial to reconstruct from git alone, and the Skill already auto-commits at the terminal event (no new commit needed). The "tier 2" candidates already evaluated and held back are `hstack-security-review` and `hstack-data-review`; both pass the criteria but their data is already first-class in frontmatter, so the sidecar's only value is parse-cost reduction. Promote them when WS-2 body parsing becomes a felt bottleneck.

package/template/templates/test-plan.md

@@ -1,119 +0,0 @@
----
-id: <parent-change-id>-test-plan
-type: test-plan
-status: draft                          # draft | in-progress | passed | concerns-acknowledged | failed | superseded
-owner: <git-handle>
-parent-change: <change-spec-id>
-scoring-mode: llm-strategized          # v1; v2 introduces 'executed' once mutation/coverage tooling is wired
-coverage-layers:
-  unit: not-applicable                 # addressed | partial | not-applicable
-  integration: not-applicable
-  e2e: not-applicable
-tenant-isolation-tests: []             # required non-empty when surfaces includes db | api | agent
-fixture-strategy-declared: false       # must be true before status: passed
-performance-budgets-required: false    # true when change touches hot paths or high-traffic surfaces
-challenge-prompts-answered: 0          # must equal 3
-concerns-acknowledged-by: null         # handle required when any coverage layer is `partial` and deferred
-invariants-mapped: []                  # change-spec invariant ids that have a mapped test in this plan
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Surfaces and Risk Profile
-
-_Pointer to change-spec `surfaces`. One sentence per surface naming the dominant test-risk layer it adds (e.g., "ui — interaction state regressions; db — RLS bypass risk on new table")._
-
-## Test Pyramid
-
-_Per-layer decisions: which behaviors land at which layer and why. Bias toward integration over end-to-end for behavior coverage; bias toward unit for pure functions and reducers. Name the test files that will exist; estimate count roughly. If a layer is `not-applicable`, justify in one sentence._
-
-### unit
-
-**Coverage status.** _addressed | partial | not-applicable._
-
-**Files.** _Test files in scope (relative paths)._
-
--
-
-**What's covered.** _Behaviors validated at this layer. 2–4 bullets._
-
--
-
-**Rationale.** _Why this layer is the right home for these behaviors._
-
-### integration
-
-**Coverage status.**
-
-**Files.**
-
--
-
-**What's covered.**
-
--
-
-**Rationale.**
-
-### e2e
-
-**Coverage status.**
-
-**Files.**
-
--
-
-**What's covered.**
-
--
-
-**Rationale.**
-
-## Edge Cases
-
-_Enumerate the edge cases the change must handle, and name the test that catches each. Bias toward cases the change-spec's Target Behavior does not explicitly name — empty inputs, max-length inputs, concurrent writes, partial failure, retries, idempotency, time-zone boundaries, off-by-one on pagination, NULL vs empty-string, locale-sensitive formatting. Minimum three bullets unless the change is genuinely trivial. Format: `case → test file::test name`._
-
--
--
--
-
-## Tenant Isolation Tests
-
-_Required non-empty section when `surfaces` includes `db`, `api`, or `agent`. For every new RLS-protected table, new tenant-scoped RPC, new tool boundary, or new cross-tenant data path: name an explicit negative test that proves cross-tenant reads/writes are refused. The change-spec's `tenant_isolation` invariants must each map to at least one test here. Format: `surface → test file::test name → what it proves`._
-
--
-
-## Test Data and Fixture Strategy
-
-_Required section. How test data is seeded, what factories or fixtures are reused, how tests are isolated from each other, and how multi-tenant data is partitioned in test runs. Name the factory module or fixture file. State whether tests share a database between runs (transactional rollback per test, full reset per suite, in-memory mock) and why._
-
-**Seed strategy.**
-
-**Factory / fixture module.**
-
-**Isolation between tests.**
-
-**Multi-tenant partitioning.**
-
-## Performance and Regression Budgets
-
-_Required when `performance-budgets-required: true`. For each hot path the change touches, declare a numeric budget (p50/p95 latency, throughput, payload size, query count) and the test that asserts the budget. Budgets without an asserting test are not budgets; they are wishes._
-
-| path | budget | asserting test |
-| --- | --- | --- |
-|  |  |  |
-
-## Challenge Prompts
-
-_All three required. Each answer must be at least one paragraph. These exist because the v1 mitigation for "humans miss what's missing" is to force the strategist to name gaps the planner and the implementer will not._
-
-### (a) What behavior in this change would silently pass the test suite but break in production? Name the test that would catch it, or declare that no such test is planned and justify.
-
-### (b) Which invariant from the change-spec has no corresponding negative or regression test? If every invariant has a mapped test, cite the test for each invariant by id.
-
-### (c) What concurrent, multi-tenant, or failure-mode scenario is not exercised by the planned tests? If none is plausibly relevant, justify why this change has no such scenario.
-
-## Open Concerns
-
-_When any coverage layer is `partial` and being deferred rather than addressed: enumerate what is uncovered, why it is acceptable to defer, who is acknowledging, and what tech-debt id captures the deferral. Ack must be human-confirmed by `owner` before status: concerns-acknowledged. Empty when every layer is `addressed` or `not-applicable`._

package/template/templates/threat-model.md

@@ -1,54 +0,0 @@
----
-id: threat-model
-type: threat-model
-status: drafted                        # drafted | current | needs-refresh | archived
-owner: <git-handle>
-last-quarterly-review: <YYYY-MM-DD>
-surfaces-covered: [ui, api, db, infra, agent]
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-_One section per surface in `surfaces-covered` (validator rule TM-01). Each section enumerates concrete threats with: threat description, affected assets, mitigation, mitigation evidence (pointer to code, ADR, or hardening-checklist item). Length cap: 8 threats per surface._
-
-## ui
-
-### Threat: <name>
-**Affected assets.**
-**Mitigation.**
-**Evidence.**
-
-## api
-
-### Threat: <name>
-**Affected assets.**
-**Mitigation.**
-**Evidence.**
-
-## db
-
-### Threat: <name>
-**Affected assets.**
-**Mitigation.**
-**Evidence.**
-
-## infra
-
-### Threat: <name>
-**Affected assets.**
-**Mitigation.**
-**Evidence.**
-
-## agent
-
-### Threat: <name>
-**Affected assets.**
-**Mitigation.**
-**Evidence.**
-
-## Unknowns
-
-_Challenge prompt: what threat to our multi-tenant boundary do you not yet have a mitigation for? This section must be present even when empty, to make the absence explicit (validator rule TM-02)._
-
--

package/template/templates/ui-brief.md

@@ -1,49 +0,0 @@
----
-id: <parent-change-id>-ui-brief
-type: ui-brief
-status: draft                          # draft | drafted | superseded
-owner: <git-handle>
-parent-change: <change-spec-id>
-reused-components: []                  # design-system component ids
-new-components: []                     # any non-empty entry requires a justification subsection
-design-system-version: <version>       # must match hstack/config.yaml
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Goal
-
-_One paragraph. What the UI must achieve from the user's POV._
-
-## Layouts and States
-
-_For every visible state of every new or modified surface: layout, content, interaction. Paragraph or bullets per state._
-
-## Reused Components
-
-_Bullets pointing to existing components by design-system id._
-
--
-
-## New Components
-
-_For each: name, props, justification for not reusing. Challenge prompt: why is this new and not a reuse?_
-
-### <ComponentName>
-
-**Props.** `{ ... }`
-
-**Justification.**
-
-## Copy
-
-_Exact strings the user sees. Reviewed by cofounder. Bullets._
-
--
-
-## Accessibility Notes
-
-_Anything that requires non-default handling (focus order, screen reader copy, contrast deviation). Bullets._
-
--

package/template/templates/verification.md

@@ -1,63 +0,0 @@
----
-id: <parent-change-id>-verification
-type: verification
-status: draft                          # draft | ran | passed | failed | superseded
-owner: <git-handle>
-parent-change: <change-spec-id>
-test-results:
-  unit: pending                        # pass | fail | pending | not-run
-  integration: pending
-  e2e: pending
-  lint: pending
-  typecheck: pending
-phase-coverage: {}                     # mirror of plan.steps-completed; { <phase-id>: pass | fail }
-test-plan-coverage:                    # observed-vs-promised against test-plan.md
-  edge-cases: pending                  # all-observed | partial | missing
-  tenant-isolation: pending            # all-observed | partial | missing | not-applicable
-  performance-budgets: pending         # all-within-budget | regressed | missing | not-applicable
-artifacts:
-  test-output: <path>
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Summary
-
-_Single-sentence verdict._
-
-## Per-Phase Outcomes
-
-_Table of phase id, verifier expectations met (yes/no), notes. Three columns max._
-
-| phase-id | met | notes |
-| --- | --- | --- |
-|  |  |  |
-
-## Test-Plan Coverage
-
-_Observed-vs-promised against `test-plan.md`. Three subsections; populate only those that apply to this change._
-
-### Edge Cases
-
-_Every bullet in the test-plan's Edge Cases section maps to an observed test. Absent or skipped tests are listed with a recommended action._
-
-### Tenant Isolation
-
-_Every entry in the test-plan's `tenant-isolation-tests` array maps to an observed negative test. Absences here are high-severity and escalate to adversarial-review (V-03)._
-
-### Performance Budgets
-
-_Every row in the test-plan's Budgets table maps to an observed assertion within budget. Regressions and absences block `status: passed` (V-04)._
-
-| path | budget | observed | within budget |
-| --- | --- | --- | --- |
-|  |  |  |  |
-
-## Test Suite Output
-
-_Pointer to the captured stdout/stderr blob (`artifacts.test-output`)._
-
-## Discrepancies
-
-_Anything the verifier observed that the plan did not predict, with an action (file an issue, escalate to adversarial-review)._

package/template/templates/vision.md

@@ -1,34 +0,0 @@
----
-id: vision
-type: vision
-status: drafted                        # drafted | current | needs-refresh | archived
-owner: <git-handle>
-reviewed-quarterly-on: <YYYY-MM-DD>
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## What this product is
-
-_Two or three sentences naming the product and category._
-
-## What it does
-
-_Top 3–5 user-visible capabilities. Bullets._
-
--
-
-## What it explicitly is not
-
-_Boundaries we are committing not to cross. Bullets._
-
--
-
-## Who it is for
-
-_Pointer to personas. Not a duplication of persona content._
-
-## Why now
-
-_The timing thesis. Two or three sentences._