hstack 0.1.0

package/template/templates/mvp-scope.md

@@ -0,0 +1,34 @@
+---
+id: mvp-scope
+type: mvp-scope
+status: drafted                        # drafted | current | needs-refresh | archived
+owner: <git-handle>
+mvp-target-date: <YYYY-MM-DD>
+created: <YYYY-MM-DD>
+updated: <YYYY-MM-DD>
+schema-version: 1
+---
+
+## In MVP
+
+_Bullets. One feature or story per line. Each entry must be either a story id or a feature-cluster name (validator rule MS-01)._
+
+-
+
+## v2
+
+_The next-up list. Bullets._
+
+-
+
+## Deferred
+
+_Things we decided not to do yet, with the reason. Bullets._
+
+-
+
+## MVP success criteria
+
+_Concrete observable indicators that we are out of MVP. Bullets._
+
+-

package/template/templates/persona.md

@@ -0,0 +1,38 @@
+---
+id: persona-<slug>
+type: persona
+status: drafted                        # drafted | current | needs-refresh | archived
+owner: <git-handle>
+anchored-on: <design-partner-slug>
+created: <YYYY-MM-DD>
+updated: <YYYY-MM-DD>
+schema-version: 1
+---
+
+## Role
+
+_Title and seniority._
+
+## Context
+
+_Tools they use today. Team size. KPI they are measured against._
+
+## Jobs-to-be-done
+
+_Bullets._
+
+-
+
+## Edge constraints
+
+_Anything unusual: compliance, time zone, locale, accessibility, device class._
+
+-
+
+## Anti-pattern
+
+_What this persona explicitly is not. Helps prevent persona drift on future stories._
+
+## Anchored design partner
+
+_Name and contact rhythm. Private — keep this section out of any export. When persona store is in repo, the file housing this section should be in `.gitignore` (see hstack/config.yaml personas-location)._

package/template/templates/plan.md

@@ -0,0 +1,49 @@
+---
+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/security-review.md

@@ -0,0 +1,63 @@
+---
+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/story.md

@@ -0,0 +1,37 @@
+---
+id: <STORE>:<store-native-id>          # one of NOTION:<id> | LINEAR:<key> | GH:<num> | REPO:<slug>
+type: story
+status: drafted                        # drafted | ready | in-flight | shipped | archived
+owner: <git-handle>
+persona: <persona-id>                  # single persona id
+job-to-be-done: <one-sentence summary; mirrors section 1>
+success-metric: <how shipping is measured>
+linked-change-specs: []                # required non-empty when status: in-flight
+created: <YYYY-MM-DD>
+updated: <YYYY-MM-DD>
+schema-version: 1
+---
+
+## Who and Why
+
+_Persona id (pointer, not duplicated) and the job-to-be-done. 1–2 sentences._
+
+## What Shipping Looks Like
+
+_What the user sees, does, feels. One paragraph, 3–5 sentences._
+
+## Success Metric
+
+_Pointer to the `success-metric` frontmatter field with a one-sentence explanation of how it is measured._
+
+## Edge Cases the User Cares About
+
+_Challenge prompt: what does the user notice if this ships but is slightly broken? 2–5 bullets._
+
+-
+
+## Out of Scope for This Story
+
+_Adjacent functionality this story does not cover. 2–3 bullets._
+
+-

package/template/templates/tech-debt.md

@@ -0,0 +1,61 @@
+---
+id: TD-<NNNN>-<slug>
+type: tech-debt
+status: open                           # open | in-progress | resolved | wontfix | stale-no-longer-reproducible | archived
+owner: <git-handle>
+severity: low                          # critical | high | medium | low
+origin: <change-spec-id-or-found-later>
+introduced-by: <change-spec-id>        # required when origin is a change-spec; reciprocal with change-spec.creates-tech-debt
+cost: small                            # small | medium | large
+fix-sketch-effort: small
+related-modules: []
+target-resolve-by: null                # required when severity: critical
+resolution-attempted-at: null          # ISO date set when status flips open -> in-progress (resolution begun)
+resolved-by: null                      # change-spec id that resolved this debt; reciprocal with change-spec.resolves-tech-debt; required when status: resolved
+wontfix-reason: null                   # one-sentence reason; required when status: wontfix
+wontfix-accepted-alternative: null     # one-sentence note on what we are accepting instead; required when status: wontfix
+stale-verified-at: null                # ISO date the absence of the original claim was verified; required when status: stale-no-longer-reproducible
+stale-verification-method: null        # one-sentence prose evidence; required when status: stale-no-longer-reproducible
+created: <YYYY-MM-DD>
+updated: <YYYY-MM-DD>
+schema-version: 1
+---
+
+## Title
+
+_Short noun phrase._
+
+## Why we took the shortcut
+
+_One or two sentences._
+
+## What it costs us
+
+_Observable cost today, projected cost at scale._
+
+## Fix sketch
+
+_What fixing would look like — code shape, scope, side effects._
+
+## Pre-conditions for fixing
+
+_What must be true first (other dependencies resolved, design tokens normalized, etc.)._
+
+## Acceptance
+
+_What "resolved" looks like — observable, verifiable bullets the adversarial-reviewer can check against the resolving change's diff. The resolving change-spec's Target Behavior must satisfy these bullets verbatim or as a superset. Once `status: resolved`, no field rewrites are permitted (TD-03)._
+
+## Resolution Log
+
+_Populated by `spec-author` as the resolution progresses. Section is empty until the first transition out of `open`._
+
+- `status: open → in-progress` on `<resolution-attempted-at>` by `<owner>`. Triggered by `/hstack:tech-debt-resolve <id>`. Resolving change-spec scaffolded at `<change-spec-id>`.
+- `status: in-progress → resolved` on `<date>` by `<owner>`. Resolving change-spec: `<change-spec-id>`. Adversarial-review Acceptance-satisfied confirmation: `<adversarial-review-id>`.
+
+_Alternatively, for the wontfix path:_
+
+- `status: open → wontfix` on `<date>` by `<owner>`. Reason: `<wontfix-reason>`. Accepted alternative: `<wontfix-accepted-alternative>`.
+
+_Alternatively, for the stale-no-longer-reproducible path (the claim aged out before anyone resolved it):_
+
+- `status: open → stale-no-longer-reproducible` on `<stale-verified-at>` by `<owner>`. Verification method: `<stale-verification-method>`.

package/template/templates/tech-stack.md

@@ -0,0 +1,41 @@
+---
+id: tech-stack
+type: tech-stack
+status: drafted                        # drafted | current | needs-refresh | archived
+owner: <git-handle>
+created: <YYYY-MM-DD>
+updated: <YYYY-MM-DD>
+schema-version: 1
+---
+
+_Each entry below: name, version pin, why. Validator rule TS-01: every named dependency must be present in package.json at the pinned version._
+
+## Application
+
+_Framework, runtime, language._
+
+-
+
+## Data
+
+_Primary store, caches, vector store._
+
+-
+
+## AI
+
+_LLM providers, embedding providers, orchestration libs._
+
+-
+
+## Integrations
+
+_Third-party platforms and the protocol layer (OAuth via Pipedream, webhook handlers)._
+
+-
+
+## Operations
+
+_CI, hosting, observability, error tracking._
+
+-

package/template/templates/telemetry-sidecar.md

@@ -0,0 +1,184 @@
+# 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

@@ -0,0 +1,119 @@
+---
+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`._