hstack 0.7.1 → 0.17.0

package/template/templates/discovery/brainstorm.md

@@ -1,69 +0,0 @@
----
-id: discovery-brainstorm
-type: discovery-technique
-technique: brainstorm
-applies-to: product-brief
-schema-version: 1
----
-
-# Brainstorm — technique script
-
-This is the prompt sequence `product-discovery` runs in Brainstorm mode. Use this when the engineer has a problem domain but no concrete concept. The mode is **facilitated ideation** — the agent acts as coach pulling ideas out via structured exercises, not generating ideas for the engineer.
-
-## Pre-flight check
-
-Before entering the script, the agent confirms:
-
-- The engineer can name the problem domain in one sentence ("CS teams losing follow-up context") even if the solution is undefined.
-- The engineer has 60+ minutes available. Brainstorm runs multi-round; cutting it short produces shallow output.
-
-## Round 1 — SCAMPER pass on the problem statement
-
-For each SCAMPER lens, ask the engineer one question and write their answer:
-
-- **Substitute** — "What current workflow could be substituted away?"
-- **Combine** — "What two things, combined, would create new value here?"
-- **Adapt** — "What other industry has solved a similar pain — what did they do?"
-- **Modify** — "What single behavior, if amplified, would solve most of the pain?"
-- **Put to another use** — "What's a non-obvious user who has this same pain?"
-- **Eliminate** — "What part of the current workflow could disappear entirely?"
-- **Reverse** — "What if the user did the opposite of what they do today?"
-
-Answers land as raw text in a scratch section. Do NOT synthesize yet.
-
-## Round 2 — Reverse brainstorming
-
-Ask: "How would you make this problem **worse** for the user? List five ways."
-
-The engineer's answers reveal the load-bearing failure modes — the things the product must NOT do. These directly seed the **Explicitly NOT** section of the brief.
-
-## Round 3 — Six Thinking Hats on the strongest thread
-
-The agent picks the strongest 1–2 threads from Rounds 1 and 2 (the threads with the most concrete user actions named) and proposes them back. For each thread, walk the hats:
-
-- **White hat (facts)** — "What do we observably know about this user's workflow today?"
-- **Red hat (intuition)** — "What feels right or wrong about this thread, gut-check?"
-- **Black hat (caution)** — "What's the strongest case against this thread?"
-- **Yellow hat (optimism)** — "What's the strongest case for this thread?"
-- **Green hat (creativity)** — "What's the wildest version of this thread?"
-- **Blue hat (process)** — "Is this the right thread to deepen, or should we drop it?"
-
-After the Six Hats run, the engineer either commits to a thread or returns to Round 1 with a sharper problem statement.
-
-## Round 4 — Synthesis
-
-The agent proposes a one-paragraph synthesis of the strongest thread, framed as: "Here is what I heard you converge on. Concept: X. Underlying pain: Y. Target user: Z." The engineer confirms or revises.
-
-On confirmation, the agent transitions to the **product-brief.md** template and walks the sections, using the synthesis as the seed for Underlying Pain, Target User, and Value Proposition.
-
-## Required reframes (mandatory before brief lands)
-
-These run during the section walk of `product-brief.md`, regardless of which Brainstorm round produced the synthesis:
-
-- "Who specifically pays for this?" — concrete persona required.
-- "What's the smallest useful wedge?" — minimum shippable surface required.
-- "What would you have to believe to be wrong about this?" — falsifiability required.
-
-## Park-and-resume
-
-The agent surfaces a parking offer after each Round commits. If the engineer parks, the round's output is persisted in `hstack/.session-state/<session-id>.yaml`. Resume picks up at the next round.

package/template/templates/discovery/forcing-questions.md

@@ -1,76 +0,0 @@
----
-id: discovery-forcing-questions
-type: discovery-technique
-technique: forcing-questions
-applies-to: product-brief
-schema-version: 1
----
-
-# Forcing-questions — technique script
-
-This is the prompt sequence `product-discovery` runs in Forcing-Questions mode. Use this when the engineer has a concept but it's vague or oversold — the technique probes claims and reframes the underlying pain. Pattern derived from YC-partner forcing questions and the Gstack approach.
-
-The agent's operating mode in this technique is **reframe-driven probing**: every claim the engineer makes triggers a reframe. The engineer's job is to defend the claim or accept the reframe. The brief converges only when the claims survive the probes.
-
-## Pre-flight check
-
-Before entering the script, the agent confirms:
-
-- The engineer has a concept they can state in one or two sentences.
-- The engineer is open to being wrong about their concept. The technique surfaces reframes that may invalidate the founder's first articulation; founders who can't tolerate that should pick Project-Brief mode instead.
-
-## Probe 1 — The 10-star reframe
-
-Ask: "What's the 10-star product hiding inside this request? What you described is 5-star; what's the 10-star version that solves the actual underlying pain?"
-
-The engineer's first answer is often a feature embellishment ("...with AI"). Re-ask: "That's a feature. What's the **underlying** pain — what does the user fail to do today that the 10-star product would make trivial?"
-
-The reframe sticks when the engineer names a pain that is one level deeper than the original concept. The brief's **Underlying Pain** section seeds from this answer.
-
-## Probe 2 — The smallest useful wedge
-
-Ask: "What's the smallest useful wedge? If you shipped one slice of the 10-star product and nothing else, what's the one slice that would still get a real user to pay?"
-
-The engineer's first answer is usually too large. Re-ask: "Cut it in half. What's left when you remove every feature that isn't load-bearing for the slice you just described?"
-
-The reframe sticks when the engineer names a wedge that can be built by one engineer in a quarter and that, alone, would justify a real user's payment. The brief's **Smallest Useful Wedge** section seeds from this answer.
-
-## Probe 3 — The named user
-
-Ask: "Who specifically pays for this? Name a real person — first name, role, company-size band, and the workflow this product enters on a Tuesday morning."
-
-The engineer's first answer is often a role abstraction ("Directors of CS"). Re-ask: "Pick one specific Director of CS you've talked to. What's her name, what's her company's name, and what does she do on a Tuesday morning that this product changes?"
-
-If the engineer cannot name a specific person, halt and surface: "The named-user constraint isn't met. We can either (a) park here and you go talk to three real users this week, or (b) acknowledge in the brief that this is anchored on a hypothetical user, which makes everything downstream a gamble." Founders sometimes choose (b); the brief records the choice in **Open Risks**.
-
-The brief's **Target User** section seeds from this answer.
-
-## Probe 4 — The falsification probe
-
-Ask: "What would you have to believe to be wrong about this concept? Name the belief and the evidence that would falsify it."
-
-The engineer's first answer is often "users won't like it" — too vague. Re-ask: "Be specific. What's a load-bearing assumption about the user, the market, or the technology that, if wrong, kills the product? And what experiment would tell you if it's wrong?"
-
-The reframe sticks when the engineer names a falsifiable belief plus an experiment that would resolve it within weeks. The brief's **Open Risks** section seeds from this answer.
-
-## Probe 5 — The scope-reduction question
-
-Ask: "If you had to ship in 8 weeks with one engineer, what would you cut? Walk me through the cut list."
-
-The engineer's cuts reveal what they think is load-bearing vs. embellishment. The brief's **Explicitly NOT** section seeds from the cut list — the things the engineer would cut are exactly the things v1 explicitly does NOT do.
-
-## Probe 6 — The reframe-staleness check
-
-After Probes 1–5, the agent surfaces: "The brief is converging on [X]. Your starting concept was [Y]. Any external documents (Notion pages, pitch deck, README) still naming [Y]? Those are now stale. Cleanup checklist:"
-
-The engineer either confirms the docs are stale and lists them for cleanup, or pushes back ("no, Y is still the framing") — in which case the agent re-runs Probe 1 to reconcile.
-
-## Synthesis
-
-After all six probes, the agent proposes a one-paragraph synthesis: "Here is what survived the probes. Concept: [refined X]. Underlying pain: [Probe 1 answer]. Smallest wedge: [Probe 2 answer]. Named user: [Probe 3 answer]. Falsification: [Probe 4 answer]." The engineer confirms or revises.
-
-On confirmation, the agent transitions to the **product-brief.md** template and walks the sections. The probe answers seed the corresponding brief sections; the Forcing-Prompt Answers section records the probes verbatim as evidence the technique ran.
-
-## Park-and-resume
-
-The agent surfaces a parking offer after each probe commits. If the engineer parks, the probe's output is persisted in `hstack/.session-state/<session-id>.yaml`. Resume picks up at the next probe.

package/template/templates/discovery/project-brief.md

@@ -1,53 +0,0 @@
----
-id: discovery-project-brief
-type: discovery-technique
-technique: project-brief
-applies-to: product-brief
-schema-version: 1
----
-
-# Project-brief — technique script
-
-This is the prompt sequence `product-discovery` runs in Project-Brief mode. Use this when the engineer is already concrete about the product and just needs structure to land the brief artifact. This is the **lightest-touch** technique — collaborative, structured, no heavy reframes — but the three required forcing prompts still fire.
-
-The agent's operating mode in this technique is **structured walk**: the engineer's existing thinking is the proposal layer; the agent prompts section by section, confirms or revises, lands the brief.
-
-## Pre-flight check
-
-Before entering the script, the agent confirms:
-
-- The engineer can state the concept in two or three sentences without hedging.
-- The engineer can name a specific real user (not a role abstraction).
-- The engineer can name a concrete success metric.
-
-If any of the three fails the concreteness floor, the agent halts and suggests switching to Forcing-Questions mode — the engineer's thinking is too vague for Project-Brief mode, which assumes concreteness.
-
-## Section walk
-
-The agent walks `product-brief.md` section by section. For each section, the agent asks one open question, accepts the engineer's answer, surfaces one clarifying re-ask if the answer is vague, then commits the section.
-
-1. **Underlying Pain** — "Describe what the user struggles with today, in concrete terms. A Tuesday-morning workflow vignette is the unit of clarity."
-2. **Target User** — "Name a specific real user. First name, role, company-size band, the tools they use, the workflow this product enters."
-3. **Value Proposition** — "What outcome does this product deliver to the named user? Outcome, not features."
-4. **Smallest Useful Wedge** — "What's the minimum shippable surface that delivers real value? Would the named user still pay for the wedge alone?"
-5. **Success Criteria** — "What measurable, time-bound outcome tells you v1 worked? Concrete number, concrete window."
-6. **Explicitly NOT** — "What is this product NOT? Two bullets minimum. What population it does NOT serve, what workflows it does NOT enter, what features it does NOT include."
-7. **Open Risks** — "What could make this product fail? Name at least one belief that, if wrong, kills the product."
-
-## Required forcing prompts
-
-Even in this lightest-touch mode, the three required forcing prompts MUST run before the brief can land. They run after the section walk completes:
-
-- "Who specifically pays for this?" — re-prompt the engineer to defend the Target User against the buyer question. The Target User and the buyer may be different (Maya the Director of CS uses it; her CFO pays for it). Both must be named.
-- "What's the smallest useful wedge?" — re-prompt the engineer to defend the wedge against the "would the user pay for the wedge alone?" question. Yes required.
-- "What would you have to believe to be wrong about this?" — re-prompt for a falsifiable belief + experiment to resolve it. Names the load-bearing risk.
-
-These three answers are logged in the brief's **Forcing-Prompt Answers** section as evidence the probes ran. The engineer cannot skip them; the technique downgrades to Forcing-Questions mode mid-session if the engineer refuses any of the three.
-
-## Synthesis
-
-There is no explicit synthesis step in Project-Brief mode — the section walk IS the synthesis. The brief lands at `status: current` when the last section commits and the three forcing prompts are answered.
-
-## Park-and-resume
-
-The agent surfaces a parking offer after each section commits. If the engineer parks, the section's output is on disk and `hstack/.session-state/<session-id>.yaml` records the next-section pointer. Resume picks up at the next section.

package/template/templates/figma-handoff.md

@@ -1,38 +0,0 @@
----
-id: <parent-change-id>-figma
-type: figma-handoff
-status: draft                          # draft | ready | superseded
-owner: <cofounder-handle>
-parent-change: <change-spec-id>
-figma-frame-urls: []                   # list of Figma frame URLs
-design-system-version: <version>       # must match parent ui-brief.design-system-version
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Frame Index
-
-_Table of frame URLs with state descriptions. Three columns max._
-
-| state | frame URL | notes |
-| --- | --- | --- |
-|  |  |  |
-
-## Implementation Notes
-
-_Anything the engineer needs to know that Figma cannot encode: animation timings, conditional rendering, copy fallbacks._
-
-## Open Questions
-
-_Anything the cofounder is uncertain about. Resolve before status: ready._
-
-## Tokens Used
-
-_Design tokens consumed. Flag any new tokens introduced — they belong in the design system, not in this change._
-
--
-
-## Sign-off
-
-_Cofounder confirms screens are final. Initials + date._

package/template/templates/glossary.md

@@ -1,20 +0,0 @@
----
-id: glossary
-type: glossary
-status: drafted                        # drafted | current | needs-refresh | archived
-owner: <git-handle>
-term-count: 0                          # must match the number of term subsections in the body
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-_Terms with non-obvious meaning in the product. One subsection per term, alphabetical order. Each term: one-paragraph definition, one or more examples, cross-references to other terms or modules. Length cap: two paragraphs per term. Update `term-count` whenever a term is added or removed (validator rule GL-01)._
-
-## <Term>
-
-**Definition.**
-
-**Example.**
-
-**See also.**

package/template/templates/hardening-checklist.md

@@ -1,73 +0,0 @@
----
-id: hardening-checklist
-type: hardening-checklist
-status: drafted                        # drafted | current | needs-refresh | archived
-owner: <git-handle>
-last-quarterly-review: <YYYY-MM-DD>
-layer-count: 10
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-_One section per layer. Each layer enumerates items with: item id, what it asserts, evidence required, not-applicable conditions. This is the artifact `security-review.md` scores against item-by-item. Validator rule HC-01: every layer that appears in a security-review `scores` map must exist as a section here._
-
-## data-at-rest
-
-### Item HC-DAR-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## data-in-transit
-
-### Item HC-DIT-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## authn
-
-### Item HC-AN-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## authz-rls
-
-### Item HC-AZ-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## tenant-isolation
-
-### Item HC-TI-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## input-validation
-
-### Item HC-IV-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## output-encoding
-
-### Item HC-OE-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## secrets-handling
-
-### Item HC-SH-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## agent-prompt-injection
-
-### Item HC-API-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**
-
-## audit-logging
-
-### Item HC-AL-01: <assertion>
-**Evidence required.**
-**Not-applicable when.**

package/template/templates/incident-runbook.md

@@ -1,57 +0,0 @@
----
-id: incident-runbook
-type: incident-runbook
-status: drafted                        # drafted | current | needs-refresh | archived
-owner: <git-handle>
-git-ignored: true                      # this file MUST be gitignored; sensitive content
-last-quarterly-review: <YYYY-MM-DD>
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-<!--
-WARNING: This file contains sensitive operational content (auth provider details, revocation endpoints,
-customer communication templates, phone tree). It MUST be gitignored. Per architecture amendment A7,
-the file lives locally and is synced to an out-of-band destination configured in hstack/config.yaml as
-`incident-runbook.sync-target`. Auto-commit does not apply to this file. The init Skill must add the
-entry to .gitignore as part of bootstrap.
--->
-
-## Kill switches
-
-_Feature flags and how to flip them, ordered by blast radius. Most-dangerous-first._
-
--
-
-## Revocation flows
-
-_Per third-party: Stripe, Supabase, Pipedream, MCPs. Steps to revoke a session, an OAuth token, an API key._
-
-### Stripe
-
-### Supabase
-
-### Pipedream
-
-### MCPs
-
-## Customer communication
-
-_Copy templates per severity (P0 / P1 / P2). Channels (in-app, email, status page)._
-
-### P0 template
-
-### P1 template
-
-### P2 template
-
-## Escalation contacts
-
-_Owner phone tree. Mark each entry with privacy boundary (work-hours OK / 24-7 OK)._
-
--
-
-## Post-incident
-
-_Runbook for the followup ADR or tech-debt write-up. Pointer to ADR template._

package/template/templates/kernel-fit-finding.md

@@ -1,63 +0,0 @@
----
-id: KF-<NNNN>-<slug>
-type: kernel-fit-finding
-status: open                           # open | acknowledged | dismissed | promoted | superseded | archived
-owner: null                            # git-handle of the triager; null until first triage
-pattern: <KF-P1 | KF-P2 | KF-P3 | …>   # detector pattern that fired; enumerated in scripts/telemetry/insights/kernel_fit.py
-confidence: medium                     # high | medium | low
-detected-by: kernel-fit-analyst
-detected-via: detector                 # detector | flag — `detector` (default) when the finding came from kernel_fit.py pattern matching; `flag` when the finding originated from a /hstack:flag pin (ADR-0005). For folded-in findings (flag signal merged into an existing detector-finding), `detected-via` remains `detector` because the originating signal was the detector pattern.
-detected-at: <ISO-8601 timestamp>
-evidence-row-count: 0                  # integer; must equal len(evidence-rows) per KF-01
-evidence-rows: []                      # YAML array of {change|adr|td, signal} dicts; one entry per row counted above
-related-findings: []                   # KF ids — prior or adjacent findings on the same kernel surface
-promoted-to: null                      # `adr:<ADR-NNNN-slug>` | `tech-debt:<TD-NNNN-slug>` | null; reciprocal with the target artifact's `promoted-from-kernel-fit`; required when status: promoted
-dismissed-reason: null                 # ≥50 chars of prose; required when status: dismissed (per KF-05)
-superseded-by: null                    # KF id when status: superseded
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Title
-
-_Short noun phrase naming the kernel-fit gap. Example: "Category-A claim spans production paths — engineer likely meant Category B."_
-
-## Pattern fired
-
-_Name the detector pattern (KF-P1 / KF-P2 / KF-P3 / …) and one paragraph describing what the detector found. Quote the pattern's defining condition from `kernel_fit.py` if helpful._
-
-## Evidence
-
-_Per evidence row, a 2–3 sentence prose summary with at least one inline citation (change-id, ADR-id, TD-id, commit-sha, kernel section). KF-01 requires `len(evidence-rows)` in frontmatter to equal `evidence-row-count`; the prose here must cite each row at least once. No prose without a citation._
-
-1. ...
-2. ...
-
-## Kernel surface implicated
-
-_Single-sentence pointer to the kernel section, template, validator rule, or Skill flow that the finding suggests revising. Examples: "`template/CLAUDE.md § Frontmatter contract` — the `internal-tooling` field"; "`template/templates/change-spec.md` frontmatter — `surfaces` enum"; "`/hstack:adversarial-review` precondition check at SKILL.md line 61"._
-
-## Proposed direction
-
-_One paragraph. Name a direction the kernel revision could take — split a flag, add an enum case, add a Skill precondition, amend a section. This is NOT a full ADR — that work is done by `spec-author` if and when the engineer invokes `/hstack:kernel-fit-promote`. Keep this as a sketch, not a specification._
-
-## Counter-explanations (challenge prompt — mandatory)
-
-_Two reasons this finding might NOT warrant a kernel change. If you cannot produce two, the analyst auto-downgrades `confidence` to `low` per KF-03. The challenge defends against false-positives the same way `## Consequences` § "name two consequences that look bad" defends ADRs._
-
-1. ...
-2. ...
-
-## Confidence rationale
-
-_One paragraph defending the `confidence` enum value against the validator rules. `high` requires `evidence-row-count >= 3` AND ≥2 distinct change-specs cited (KF-02). `medium` is the conservative default. `low` carries no notification and is appropriate when evidence is thin or the challenge prompts substantially weaken the finding._
-
-## Triage Log
-
-_Populated by `/hstack:kernel-fit-triage` and `/hstack:kernel-fit-promote` as the finding's status transitions. Section is empty until the first transition out of `open`._
-
-- `status: open → acknowledged` on `<YYYY-MM-DD>` by `<owner>`. Triggered by `/hstack:kernel-fit-triage <id> --action acknowledge`.
-- `status: open → dismissed` on `<YYYY-MM-DD>` by `<owner>`. Reason: `<dismissed-reason>`.
-- `status: acknowledged → promoted` on `<YYYY-MM-DD>` by `<owner>`. Promoted to: `<promoted-to>`. Triggered by `/hstack:kernel-fit-promote <id> --slug <adr-slug>`.
-- `status: open → superseded` on `<YYYY-MM-DD>` by the next `kernel-fit-analyst` run. Superseded by: `<superseded-by>`.

package/template/templates/kernel-fit-flag.md

@@ -1,52 +0,0 @@
----
-id: flag-<YYYYMMDD>T<HHMMSS>-<session-id-short>
-type: kernel-fit-flag
-status: pending                          # pending | processed
-session-id: <claude-code-session-uuid>   # FL-01: non-null at pin-time
-session-transcript-path: <abs-path-to-jsonl>  # FL-01: non-null at pin-time
-branch: <current-branch>                 # FL-01: non-null at pin-time
-head: <current-HEAD-sha>                 # FL-01: non-null at pin-time
-workspace: <abs-path-to-cwd>             # FL-01: non-null at pin-time
-timestamp: <ISO-8601 timestamp at pin>   # FL-01: non-null at pin-time
-pre-compaction-message-count: <integer>  # FL-01: non-null at pin-time; analyst uses this to detect truncation between pin and scan
-hint: null                                # one-word string from --hint arg; null when no arg given
-classification: null                      # FL-02: non-null when status: processed; one of friction | missing-guardrail | kernel-vs-practice-mismatch | not-actionable | transcript-truncated
-classification-rationale: null            # FL-02: non-null when status: processed; one-line analyst note
-folded-into: null                         # KF-NNNN-<slug> when the analyst folded the signal into an existing finding
-emitted-as: null                          # KF-NNNN-<slug> when the analyst emitted a fresh finding from this pin
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-<!--
-A kernel-fit-flag is a frontmatter-only pin. There is no body. Engineer
-interpretation of the friction is deliberately excluded — the analyst reads
-the transcript window and forms its own classification at processing time.
-
-Validator rules (enforced by the proposed-diff preview in v1; validate-spec.ts
-is still a {{TODO-SCRIPT}} placeholder):
-
-- FL-01: at pin-time (status: pending) every field marked above as
-  "non-null at pin-time" must be populated. `hint` may be null; the four
-  analyst-owned fields (classification, classification-rationale,
-  folded-into, emitted-as) must remain null until processing.
-
-- FL-02: at processing-time (status: processed) `classification` and
-  `classification-rationale` must both be non-null. When the classification
-  produced a finding, exactly one of `folded-into` or `emitted-as` is non-null
-  (never both). When the classification did not produce a finding (closed as
-  `not-actionable` or `transcript-truncated`), both remain null.
-
-Pins are immutable from the engineer's perspective. The only legal writes
-after creation are by the kernel-fit-analyst at processing time, setting the
-four analyst-owned fields and flipping status to processed. The engineer
-cannot edit a pin to add commentary — that would re-open the contamination
-surface the analyst guards against. To add context, re-flag in a follow-up
-turn (a new pin with a different timestamp).
-
-Pins live at hstack/kernel-fit/flags/pending/ before processing and at
-hstack/kernel-fit/flags/processed/ after. The directory is gitignored in
-the consuming repo — see ADR-0005 for the rationale and the trade-off
-(provenance gap unique to this artifact type).
--->

package/template/templates/module-spec.md

@@ -1,49 +0,0 @@
----
-id: <module-key>                       # equals the module key in hstack/config.yaml
-type: module-spec
-status: drafted                        # drafted | current | needs-refresh | archived
-owner: <git-handle>
-paths: []                              # required; canonical module-to-paths mapping (globs)
-last-refreshed: <YYYY-MM-DD>
-created: <YYYY-MM-DD>
-updated: <YYYY-MM-DD>
-schema-version: 1
----
-
-## Purpose
-
-_What this module is responsible for. 2–4 sentences. Author may grep `paths` to verify._
-
-## Public Surface
-
-_Exports, routes, RPCs the module exposes outward. Bullets._
-
--
-
-## Data Owned
-
-_Tables, columns, and indexes this module is the canonical owner of. Bullets._
-
--
-
-## External Dependencies
-
-_Other modules, third-party services, MCPs this module depends on. Bullets._
-
--
-
-## Invariants
-
-_Challenge prompt: what would a careless refactor in this module break that the tests would not catch? Minimum 3 bullets (validator rule MS-03)._
-
--
--
--
-
-## Known Tech-Debt and ADRs
-
-_Pointers._
-
-## Refresh Policy
-
-_What triggers a refresh and what the refresh entails. One paragraph. The 60-day `needs-refresh` cron flags this spec if untouched._

package/template/templates/mvp-scope.md

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

@@ -1,38 +0,0 @@
----
-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)._