@baldurpan/create-ai-workflow 0.2.0

package/templates/stubs/findings.md

@@ -0,0 +1,40 @@
+# Findings
+
+Defects that outlive the session that found them. A reviewer `FAIL`, a verification gate that hits its
+loopback cap, or a defect found by hand all land here — **before** the loopback, not after it, so a finding
+survives even when the cap is hit and the task is escalated.
+
+## Contract
+
+**Severity.** `P0` breaks production or data. `P1` blocks a phase or a gate. `P2` is a real defect that
+does not block. `P3` is a note worth not losing.
+
+**Tied to.** Either a phase — `<feature-name> Phase <n>` — or `ad-hoc` for a finding raised by
+`/orchestrate` outside any feature.
+
+**Gating.** An open `P0` or `P1` tied to a phase blocks that phase from being marked `done`, and blocks
+`/feature-close` on the feature that owns it.
+
+**Closing.** A finding closes when **the gate that raised it re-passes**, citing that run. There is no
+"fixed but unverified" state — that implies an owner this workflow does not have.
+
+**Bound.** Closed findings leave this file: a feature's at `/feature-close`, folded into the retiring
+plan's own log; an `ad-hoc` one at the start of the next `/orchestrate`. This file must not grow for the
+life of the project.
+
+**Shape.** Entries go under **Open** below, newest last, and look like this:
+
+> ### F-001 — P1 — one line naming the defect
+>
+> **Tied to:** some-feature Phase 2 · **Raised:** YYYY-MM-DD (by the gate that raised it, or "hand")
+>
+> What is wrong, where, and why it matters. Cite the file and the evidence.
+>
+> **Closes when:** the condition that closes it, naming the gate run that would prove it.
+
+---
+
+## Open
+
+## Closed
+

package/templates/stubs/history.md

@@ -0,0 +1,13 @@
+# History
+
+Retired features, newest last. Append-only — written by `/feature-close`, one row per feature, never edited
+afterwards.
+
+This file **indexes** depth rather than duplicating it: the reasoning stays in the archived plan document,
+so a row never grows and this file gains one line per feature.
+
+`dropped` is the load-bearing case. An idea killed before it ever got a plan document leaves no trace
+except git history, and this row is what stops it being re-proposed.
+
+| Date | Feature | Outcome | Why | Document |
+|---|---|---|---|---|

package/templates/stubs/roadmap.md

@@ -0,0 +1,29 @@
+# Roadmap
+
+Tier 1 — the backlog. High-level by design: depth belongs in the plan document, not here.
+
+Only `pending` and `active` entries live in this file. Finished and abandoned entries leave entirely, via
+`/feature-close`, and are indexed in [`history.md`](history.md).
+
+**An entry's status is the marker in its heading, and nowhere else.** At most one entry is `active` at a
+time. There is no "active" section and no summary line — a second place to say the same thing is a second
+place for it to go stale. To know what is being worked, scan for the marker.
+
+Each entry's **Doc** field points at its document, and the path says what stage it is at: `drafts/` is
+notes, `plans/` is a real plan with a phase ledger. `pending` with a `plans/` document means planned but
+not being worked — that is a normal state, not a discrepancy.
+
+Add an entry with `/roadmap "some idea"`. Turn one into a plan with `/feature-plan`. Entries look like
+this, appended under **Features** below:
+
+> ### some-feature-name — `pending`
+>
+> One or two lines: the problem, or what becomes possible. Not a design.
+>
+> - **Size:** small — what drives the size, a few words
+> - **Doc:** none yet
+
+---
+
+## Features
+

package/templates/stubs/stack.md

@@ -0,0 +1,35 @@
+# Stack
+
+What this project is, and what an agent has to know before touching it. Run `/onboard` to fill it in.
+
+<!-- One paragraph: what the project does, and anything about its history that explains why it is shaped
+     the way it is. -->
+
+| Concern | Target |
+|---|---|
+| Runtime | |
+| Package manager | |
+| Database | |
+| Storage | |
+| Hosting | |
+
+## Layout
+
+```
+<!-- The directories that matter, one line each on what lives there. -->
+```
+
+## Conventions
+
+<!-- The rules that are specific to this repo and would not be guessed: things that break in this runtime,
+     things deliberately kept separate, where local secrets live, what must never be run against
+     production. -->
+
+## Also in `context/`
+
+<!-- Index anything you add under context/ here — decisions.md, glossary.md, ops-notes.md. Not in
+     context/README.md: that file is tool-owned and replaced on every update, so a line added there is a
+     line lost. -->
+
+Verification commands are in [`verify.md`](verify.md), not here. Executor dispatch is in
+[`executors.md`](executors.md).

package/templates/stubs/verify.md

@@ -0,0 +1,48 @@
+# Verification commands
+
+This project's real verification stack. **Gate 1 reads this file** — no skill, agent prompt or role file
+carries a copy of these commands, because a hardcoded stack rots the moment the project changes shape.
+
+This is the single home for every command in this project. If you find a command written down anywhere else
+in `context/`, that copy is the one that is wrong.
+
+Keep it in step with CI. If a command here fails while CI is green, this file is the one that is wrong.
+
+Run `/onboard` to fill these sections in — it proposes candidates, **runs each one, and writes only the
+ones that exit 0.** Filling them in by hand is fine too; running them first is not optional either way.
+
+<!-- Prerequisites, if any: node version, package manager, install step already run, services up. -->
+
+## Lint
+
+```bash
+```
+
+## Typecheck
+
+```bash
+```
+
+## Build
+
+```bash
+```
+
+## Test
+
+```bash
+```
+
+## Not run by Gate 1
+
+<!-- Commands that need Docker, a cloud account, or a deploy target. CI and deploy concerns, not
+     per-task verification. List them here so nobody adds them above by mistake. -->
+
+## Rules
+
+- **A missing entry is skipped, never faked.** An empty section above means there is no such step. Gate 1
+  skips it and says so; it never substitutes a command it invented.
+- **Docs-only changes run Lint only**, plus a read of the diff. Skip build and test for changes that touch
+  no application code.
+- **Exit 0 is the verdict.** A non-zero exit is a Gate 1 failure regardless of what the summary text says.
+- **If this file has no filled-in section at all, Gate 1 stops and says so.** It does not guess.