@zalom/plastic 1.14.0 → 2.0.0-alpha.1

package/skills/intent-executing/plan-reviewer-prompt.md

@@ -0,0 +1,39 @@
+# Adversarial Plan Reviewer Prompt
+
+You review a plan before any code exists. The lead of this intent wrote `spec.md`, `plan.md`,
+and at least one `actions/ACTION_N.md` that carries a failure-mode matrix: one row per
+operation, naming a failure mode and the test that would catch it. Your job is to find what
+that matrix misses and what it claims but cannot deliver, so the executor builds against a
+plan that has already been attacked.
+
+## Intent
+
+{{INTENT_DIR}} (read `spec.md`, `plan.md`, every `actions/ACTION_N.md`, and anything under
+`resources/` the spec cites). Target tree: {{WORKTREE}}.
+
+## Instructions
+
+1. Read the spec's decisions and the matrix first, then the tree. Check every claim by
+   opening the named file at the named line; never accept a line number from the spec on
+   trust.
+2. For every operation in the spec, name a failure mode the matrix does not cover, or a
+   covered failure mode whose named test cannot actually detect it (the test reads a
+   different file, the regex cannot match, the assertion is a tautology, the fixture never
+   produces the case).
+3. Grep the tree for every name the plan deletes, renames, or re-points, and list each
+   caller, test, doc, or template the plan does not name.
+4. Where the plan touches a test the suite pins by exact string, quote the pinned string and
+   say what the change must keep verbatim.
+5. Run any probe that settles a claim cheaply (a single test file, a measurement); report the
+   numbers.
+6. Write no code and edit no repository file. Your output is the review.
+
+## Report Format
+
+One line first, the verdict: **REVISE** or **PROCEED**, with the biggest risk in the same
+sentence.
+
+Then numbered findings under `## A. Matrix gaps`, `## B. Missed files and pins`, and
+`## C. Probes`. Each finding names the file and line you read and states what the spec or
+the matrix must add, change, or drop. Be concrete and adversarial; do not pad; do not restate
+the plan.

package/skills/intent-speccing/SKILL.md

@@ -1,73 +1,130 @@
 ---
 name: plastic-intent-speccing
-description: >
-  Consolidate the enriched Why (`## Context`, `### Decisions`, `## Insights`) into `spec.md`
-  through a deterministic, judgment-free numbered sequence. Use when the user types the command
-  to turn the brainstorm into a spec, asks to "write the spec", "spec this intent", "consolidate
-  into spec.md", or the active intent is at Why with enough Decisions on record to close it out.
-  Also fires on an indirect request that never names spec.md, such as "turn what we just
-  discussed into the contract the planner builds from." Distinct from `plastic-intent-brainstorming`
-  (the exploration that produces the enriched Why, upstream of this skill) and
-  `plastic-intent-planning` (turns an existing spec.md into plan.md for How, downstream of this
-  skill).
+description: >-
+  Thinking mode for an intent: the conversation that turns an idea into rulings, the
+  research that backs them, and the action files that say how the work runs. Use when the
+  user wants to think a request through before building it, says "let's design this",
+  "brainstorm", "grill me", "research this first", "spec this intent", "write the spec",
+  or when a prompt is too vague to run directly and the direct skill routes here. Also
+  fires on an indirect ask that never names a spec, such as "turn what we just discussed
+  into the contract the work runs from." Absorbs what the former intent-brainstorming,
+  intent-grilling, and intent-researching skills used to do (intent 304).
 user-invocable: true
 ---
 
-# Intent Speccing
+# Intent Speccing: thinking mode
 
-Consolidate the enriched Why into `spec.md` through eight fixed steps, one action per step. The
-next action is never a judgment call: when a section cannot be filled from what is on record,
-step 5 is to stop and ask, never invent.
+One skill for the whole thinking conversation on an intent. It asks one question at a time,
+records every owner ruling the moment it lands, grills when asked, deposits research in
+`resources/`, and ends by writing the action files the work runs from and consolidating the
+rulings into `spec.md`. There is no separate brainstorm, grill, or research skill; those are
+the modes below.
 
-## Precondition
+## Active intent
 
-Run only when the active intent is at Why (its `## Intent` and enriched `## Context` plus
-`### Decisions` exist, `spec.md` does not yet exist or is being redone) and the user has asked to
-consolidate that Why into the spec. If no intent is active, or the active intent is not at Why,
-report that and stop; do not guess which intent is meant.
+Resolve the active intent before anything else: read `~/.plastic/projects.yml`, match the
+working directory against registered project paths (a match means the project store at
+`~/.plastic/projects/{slug}/store/`, no match means `~/.plastic/store/`), then read that
+store's `INDEX.md` under `## Active`. Exactly one active intent is the one to work; several
+means ask which; none means stop and say so ("No active intent. Create one first with
+/plastic-intent-creating"). Every artifact goes into `{store}/{id}--{slug}/`; never write
+outside it.
 
-## The 8-step sequence
+## The conversation
 
-| Step | Action |
-|---|---|
-| 1 | Confirm the precondition above. |
-| 2 | Read inputs in fixed order and build a ruling ledger: (a) `## Context` and `### Decisions`; (b) `## Insights` newest-last, so a later ruling supersedes an earlier conflicting one; (c) `resources/discovery--<slug>.md`; (d) any other `resources/*.md`. |
-| 3 | Decide the tier: adopt the brainstorming `Tier:` recommendation from Decisions or Insights; otherwise apply the PLASTIC.md tiers rubric (S = single mechanism or file cluster, M = one subsystem, L = cross-cutting or novel design). |
-| 4 | Fill the template section by section, all 8 sections in template order. Read `references/per-section-fill-rules.md` now, filling the template is the trigger. Write the tier as the literal top line above `# Spec:`. Encode every ruling into its matching section, later supersedes earlier on conflict. A collapsed single-line S/M section is complete and valid; do not pad it. |
-| 5 | Gap rule: if any section cannot be filled from the ledger built in step 2, STOP and ask the user for the missing ruling. Never invent scope to fill a gap. |
-| 6 | State the gate position (below) so the user knows what happens next. |
-| 7 | Self-verify against the checklist. Read `references/self-verify-checklist.md` now, verifying before presenting is the trigger. Fix any failing check, then re-verify from the top. |
-| 8 | Present `spec.md` for the user-review gate, then hand off to `plastic-intent-planning` for How. |
+QMD-first: before scanning the store by hand for prior decisions, specs, or research, run
+`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` and open the authoritative intent file for
+any hit you act on. The command is a no-op when QMD is absent.
+
+1. **Context first.** Check the project state (files, docs, recent commits) and the intent's
+   `## Context` and `## Insights`. Assess scope: a request that describes several independent
+   subsystems is decomposed first, one thinking conversation per piece, before any detail
+   question is spent.
+2. **One question per message, in prose.** No multiple-choice chips; a short menu of named
+   options is fine when the choice is genuinely enumerable, phrased as a sentence. Focus on
+   purpose, constraints, and success criteria. Before asking how something works, look:
+   in a codebase the answer is usually on disk.
+3. **Propose two or three approaches** with trade-offs, leading with the recommendation and
+   the reason for it. YAGNI: strip what the design does not need.
+4. **Present the design in sections** scaled to their complexity (a few sentences when
+   straightforward, up to 300 words when nuanced): architecture, components, data flow,
+   error handling, testing. Get a ruling after each section. Read
+   `references/design-principles.md` before proposing a design for the unit-boundary and
+   existing-codebase guidance (follow established patterns, no unrelated refactoring).
+5. **Record every ruling as it lands.** The moment the owner rules, before the next question:
+   ```
+   ruby ~/.plastic/scripts/insight-append {intent_dir} "<ruling text>" --stage Why --author human
+   ```
+   Never batch. A later ruling that conflicts with an earlier one gets a new insight naming
+   the superseded one; both stay on record and the later wins. When presenting a batch of
+   options for the owner to pick from, read `~/.plastic/_decision-tables.md` and follow the
+   numbered-table procedure.
+
+No implementation starts until a design has been presented and ruled on. That holds for a
+config change and a one-function utility as much as for a subsystem; the design can be three
+sentences, but it is presented.
+
+### Grill mode
 
-## Gate position (step 6)
+When the owner says "grill me" or asks to stress-test a plan or design, the same conversation
+turns relentless. Identify the root in one sentence and restate it. Walk the decision tree
+branch by branch: state the branch, ask a specific question, lead with your own recommended
+answer, resolve before moving on, name dependencies between decisions and resolve the
+upstream one first. Do not accept "it depends" without "on what?"; do not skip edge cases; do
+not assume when you can verify; challenge assumptions ("why not the alternative?"). Every
+three or four questions, summarize what is decided. At natural checkpoints, about every ten
+questions, offer to continue or to pause and capture what is decided; a pause records every
+ruling so far and stops. When all branches are resolved, list the decisions and the deferred
+items, then offer the hand-off below.
 
-The Why stage's deliverable is `spec.md`; the gate is satisfied the moment a complete, real
-`spec.md` exists (this is the gates-by-name framing: gate-check enforces spec.md before plan.md,
-not the Transition Gates table row). Writing `plan.md` is what opens the code gate for Exec, and
-writing `plan.md` is not this skill's job, that is `plastic-intent-planning`. State this to the user
-at step 6 so the handoff at step 8 is expected, not a surprise.
+### Research mode
 
-Read `../plastic-conventions/references/lifecycle-and-savepoints.md` for the subagent
-report-home contract behind this handoff. This path resolves relative to this skill's own
-installed directory.
+When a question needs evidence rather than a ruling, research it and deposit the report in
+`{intent_dir}/resources/{type}--{topic}.md`, with `{type}` one of `deep-research`,
+`competitive-analysis`, `technical-spike`, `reference`, `landscape-survey` and `{topic}` in
+kebab-case. Choose the depth and say why: shallow (one or two searches plus a look at the
+code, minutes) for a narrow factual question; deep (several sources, cross-checked, a
+landscape or an architectural decision, or when a wrong answer would cause an architectural
+mistake) through the harness's deep-research capability when it has one, else a manual
+fan-out of searches. The report carries a summary, findings with citations, sources, and a
+"Relevance to intent" section; tables for findings and comparisons. Log one line in the
+intent's `## Insights` naming the file and the key finding. Research does not chain to
+another step; the conversation decides what to do with it.
 
-## Tier stamp (step 3, convention only)
+## Closing the conversation
 
-Write `Tier: S|M|L` as the literal first line of the file, above the `# Spec:` heading. This line
-is convention-only: the orchestrator and the planner read it, no gate and no doctor check
-validates it.
+When the rulings are enough to build from:
 
-## Completion report
+1. **Write the action files.** Every ruling that says how the work runs lands in
+   `actions/ACTION_N.md` (at least one real file, no placeholder): the files to touch, the
+   order, the tests that prove each step, the rules. The action files are what direct mode or
+   an auto team executes; they exist before the work runs.
+2. **Consolidate `spec.md`** from the rulings, section by section in template order. Read
+   `references/per-section-fill-rules.md` when filling the template. Build the ruling ledger
+   in fixed order first: `## Context` and `### Decisions`, then `## Insights` newest-last so a
+   later ruling supersedes an earlier one, then `resources/discovery--<slug>.md`, then any
+   other `resources/*.md`. Encode every ruling into its section; a collapsed single-line
+   section is complete when it names everything. If a section cannot be filled from the
+   ledger, stop and ask for the missing ruling; never invent scope. A spec.md left as the
+   placeholder is backfilled from the record at close (`## Problem`, `## Decisions`,
+   `## Acceptance Criteria`; the rest stays stub text), so consolidate only when the
+   rulings say more than the record already does.
+3. **Self-verify.** Read `references/self-verify-checklist.md` before presenting; fix any
+   failing check and re-verify from the top.
+4. **Present and hand off.** Present `spec.md` and the action files. Then offer the routes:
+   run it now inline when the work is small enough for direct mode; hand to `plastic-auto`
+   when the owner says auto and the checklist above passes (all decisions resolved, scope
+   bounded, dependencies named, success criteria defined); or keep thinking.
 
-State, in this order: which file was written (`spec.md`, new or rewritten), the stamped `Tier:`
-value, the count of Acceptance Criteria produced (the surface the planner will cover), which
-`## Insights` rulings superseded an earlier Decision (if any) and where each landed, and the
-handoff target (`plastic-intent-planning`). If step 5 stopped for a missing ruling, report that
-instead: which section, what is missing, and the question put to the user.
+Report, in this order: which files were written (`spec.md` new or rewritten, the action
+files), the count of acceptance criteria, which `## Insights` rulings superseded an earlier
+decision and where each landed, and the route chosen. If step 2 stopped for a missing
+ruling, report that instead: which section, what is missing, the question put to the owner.
 
 ## References
 
 | Trigger | Read |
 |---|---|
-| Filling the template (step 4) | `references/per-section-fill-rules.md` |
-| Self-verifying before presenting (step 7) | `references/self-verify-checklist.md` |
+| Before proposing a design (unit boundaries, existing codebases) | `references/design-principles.md` |
+| Filling the spec template (closing step 2) | `references/per-section-fill-rules.md` |
+| Self-verifying before presenting (closing step 3) | `references/self-verify-checklist.md` |

package/skills/intent-speccing/evals/evals.json

@@ -1,6 +1,6 @@
 {
   "skill_name": "plastic-intent-speccing",
-  "notes": "Intent 163. Scopes: description triggering (1-4) and behavior (5-8: all-8-sections output, mandatory superseding-ruling case, STOP-and-ask gap rule, tabular alternatives with no em-dash). No dedicated Ruby test file backs this skill yet (natural-language guided command), so all assertions are result: expect-pass pending a real observed run, per the intent-starting evals.json convention.",
+  "notes": "Intent 163. Scopes: description triggering (1-4) and behavior (5-8: all-8-sections output, mandatory superseding-ruling case, STOP-and-ask gap rule, tabular alternatives with no em-dash). No dedicated Ruby test file backs this skill yet (natural-language guided command), so all assertions are result: expect-pass pending a real observed run, per the evals.json convention.",
   "evals": [
     {
       "id": 1,
@@ -37,7 +37,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "Brainstorm this intent.",
-      "expected_output": "Does NOT activate plastic-intent-speccing; activates plastic-intent-brainstorming (exploration that produces the enriched Why, upstream of speccing).",
+      "expected_output": "Activates plastic-intent-speccing (brainstorming is a mode of the thinking conversation since intent 304).",
       "files": [],
       "assertions": [
         {
@@ -52,7 +52,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "Write the plan.",
-      "expected_output": "Does NOT activate plastic-intent-speccing; activates plastic-intent-planning (turns an existing spec.md into plan.md for How, downstream of speccing).",
+      "expected_output": "Does NOT activate plastic-intent-speccing; a plan is written from the action files by the executing skill.",
       "files": [],
       "assertions": [
         {
@@ -67,12 +67,12 @@
       "scope": "behavior",
       "set": "train",
       "prompt": "Intent Y is at Why: Context describes the problem and goal, and 5 Decisions are recorded resolving scope, approach, and one rejected alternative. Consolidate into spec.md.",
-      "expected_output": "Produces spec.md with Tier: S|M|L as the literal top line above the Spec heading; all 8 template sections present once, in template order (Problem, Goals, Non-Goals, Approach, Alternatives Considered, Decisions, Acceptance Criteria, Open Questions); no template placeholder text remains; every recorded Decision is encoded into its matching section.",
+      "expected_output": "Produces spec.md starting at the Spec heading; all 8 template sections present once, in template order (Problem, Goals, Non-Goals, Approach, Alternatives Considered, Decisions, Acceptance Criteria, Open Questions); no template placeholder text remains; every recorded Decision is encoded into its matching section.",
       "files": [],
       "assertions": [
         {
           "type": "human",
-          "check": "Tier line is literally the first line of the file; all 8 sections appear once each, in template order; no placeholder text; every Decision traces to a section",
+          "check": "The file starts at the Spec heading; all 8 sections appear once each, in template order; no placeholder text; every Decision traces to a section",
           "result": "expect-pass"
         }
       ]

package/skills/intent-speccing/references/per-section-fill-rules.md

@@ -1,8 +1,8 @@
 # Per-Section Fill Rules
 
-The single shared method for turning the enriched Why into `spec.md`. Both
-`plastic-intent-speccing` (guided) and the `plastic-spec-specialist` agent (auto) point here;
-neither restates these rules. One fill rule per template section, in template order.
+The single shared method for turning the rulings into `spec.md`. `plastic-intent-speccing`
+(the thinking conversation) and the auto orchestrator both point here; neither restates these
+rules. One fill rule per template section, in template order.
 
 Read the ruling ledger first (built in step 2 of the SKILL.md sequence): `## Context` plus
 `### Decisions`, then `## Insights` newest-last (a later ruling supersedes an earlier
@@ -24,7 +24,7 @@ delivering a specific outcome.
 
 One bullet per goal, each a concrete, observable outcome the delivery must reach. Encode every
 Decision that commits to an outcome as its own bullet, do not compress two Decisions into one
-vague goal. A single-line collapsed Goals section (S/M tier) is complete if it names every
+vague goal. A single-line collapsed Goals section is complete if it names every
 outcome; do not pad it with restated Problem text.
 
 ## 3. Non-Goals

package/skills/intent-speccing/references/self-verify-checklist.md

@@ -22,8 +22,7 @@ these.
 5. **No template placeholder text remains.** No literal `<intent name>`, `<alternative>`, `...`,
    sample bracket text, or other template filler from `templates/spec.md` survives anywhere in
    the artifact.
-6. **Tier stamp is the top line.** `Tier: S|M|L` is the literal first line of the file, above the
-   `# Spec:` heading, not folded into a section body.
+6. **No header line.** The file starts at the `# Spec:` heading; there is no `Tier:` line (removed in 2.0, intent 304).
 7. **All 8 sections present, in template order.** Problem, Goals, Non-Goals, Approach,
    Alternatives Considered, Decisions, Acceptance Criteria, Open Questions, each present once, in
    that order, none merged into another.

package/skills/project-creating/SKILL.md

@@ -77,7 +77,7 @@ writes `INDEX.md` and `project.yml` only if missing. It is idempotent, so it is
 safe even when the tactical mirror in step 5 already created the store directory.
 Do not create the store with an inline `mkdir`; the provisioner is the only place
 a store is made. For a project that is already registered but store-less, use the
-`plastic-store-provisioning` skill instead.
+`plastic-doctor` skill's provisioning section instead.
 
 ### 8. Mark Global Intent(s) Completed
 

package/skills/releasing/SKILL.md

@@ -250,16 +250,15 @@ This is the release branch of `plastic-intent-ending`'s Step 5 disarm (`merge: t
 separate concern: a release is the merge-then-remove path for the intent's worktree (intent
 73c3), so the intent's code branch is merged back into the default branch BEFORE the worktree
 is removed. Drive it through `Worktree.finish` with `merge: true`, which merges the code
-branch, then removes the worktree, prunes the repo, and clears the worktree block from the
-bridge:
+branch, then removes the worktree, and prunes the repo:
 
 ```bash
-ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/bridge -e \
-  'b = Bridge.discover_bridge(session: ENV["CLAUDE_CODE_SESSION_ID"], cwd: Dir.pwd); Worktree.finish(b, merge: true) if b'
+ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/arm -e \
+  'Worktree.finish(Arm.bridge_hash(intent_dir: "<STORE>/<dir>"), merge: true)'
 ```
 
-(Uses `discover_bridge`, not a bare session-keyed `Bridge.read`, because a session can own more
-than one live bridge now (intent 131) and `discover_bridge` resolves the right one for this cwd.)
+(The worktree block is derived from `projects.yml` and the intent id, so the one-liner needs
+only the intent directory; the `/tmp` bridge it once discovered was removed in 2.0, intent 307.)
 
 Honor the worktree-cleanup rule: never leave an orphaned worktree, and run `git worktree
 prune` in the affected repo if you hit a stale reference. For why this is the one place the
@@ -279,14 +278,14 @@ A release IS a delivery. The active intent that drove this work must be complete
       ruby ~/.plastic/scripts/end-intent --store <store_path> --id <ID> --disposition delivered \
         --session "$CLAUDE_CODE_SESSION_ID" \
         --outcome-summary "delivered in <tag-name>: <one-line summary>" \
-        --index-note "<tag-name>, <mode/tier>; <what shipped>; <suite result>"
+        --index-note "<tag-name>, <mode>; <what shipped>; <suite result>"
       ```
       A non-zero exit needs attention: 4 means a live foreign session holds the lock (back
       off), 5 means the code worktree is still dirty (should not happen here, since step 8
       already removed it; investigate before overriding with `--discard-worktree-changes`),
       3 means disarm ran but the lock is still present (run `/plastic-doctor check the lock
       status`).
-   d. Update clusters to show `_(completed)_` (the store-curating skill's job on its next pass).
+   d. Update clusters to show `_(completed)_`.
 
 **If no active intent exists for this release**, that itself is a problem - work happened outside the intent system. Log it and move on, but flag it.
 

package/skills/tutorial/SKILL.md

@@ -21,7 +21,7 @@ reference. Every checkpoint inside a track is prose, never another menu.
 
 1. **Guided**: deliver a first intent, stage by stage, approving each step yourself. Routes to
    `references/track-1-guided.md`.
-2. **Auto**: hand delivery to the agent and watch the gates and reports as it works. Routes to
+2. **Auto**: hand delivery to the agent and watch the record and reports as it works. Routes to
    `references/track-2-auto.md`.
 3. **Projects and roadmaps**: grow a founding intent into a small real project, add more
    intents, and plan a delivery batch with a roadmap. Routes to
@@ -35,7 +35,7 @@ showing the menu again.
 
 Narrate one step at a time: say what the next station does, then hand control back so the
 user types the real command themselves. After they run it, look at what appeared (a file, a
-gate message, a report) and debrief in plain words before moving to the next station. Never
+ledger line, a report) and debrief in plain words before moving to the next station. Never
 run a station's command on the user's behalf; the tutorial teaches the shape of the work, it
 does not do the work.
 

package/skills/tutorial/references/track-1-guided.md

@@ -35,19 +35,19 @@ tool, never written by hand.
 
 ### 2. Board the intent
 
-Type `/plastic-intent-starting`.
+Type `/plastic-intent-continuing` and name the intent.
 
 Artifact: a delivery lock (a `delivery.lock` file in the intent directory) naming this
 session as the one owner, and a line in `savepoint.md` recording the stage. The agent then
-asks exactly one question: "auto or guided?"
+resumes at the last delivered station and asks nothing.
 
-Checkpoint: answer "guided." Explain in one sentence why the lock matters: it stops two
+Checkpoint: explain in one sentence why the lock matters: it stops two
 sessions from editing the same intent at the same time.
 
 ### 3. Why, rulings one at a time
 
-Type `/plastic-intent-brainstorming` (or `/plastic-intent-grilling` for a harder,
-interview-style pass over the same ground). It asks conversational prose questions, one at a
+Type `/plastic-intent-speccing` (say "grill me" for a harder, interview-style pass over
+the same ground). It asks conversational prose questions, one at a
 time, never a multiple-choice menu, and answers them one at a time in return.
 
 Artifact: `## Context` and `### Decisions` in the intent file fill in as each answer lands, and
@@ -62,21 +62,19 @@ is already sitting in `### Decisions` and in `## Insights`, in writing.
 
 Type `/plastic-intent-speccing`.
 
-Artifact: `spec.md`, stamped with a tier (`S`, for this small worked example) and its eight
-sections filled from the rulings recorded in station 3.
+Artifact: `spec.md`, its eight sections filled from the rulings recorded in station 3.
 
-Checkpoint: name the stamped tier and point at one sentence in `spec.md` that traces back to
-an answer given in station 3.
+Checkpoint: point at one sentence in `spec.md` that traces back to an answer given in
+station 3.
 
 ### 5. Plan
 
-Type `/plastic-intent-planning`.
+Ask the same conversation to write the action files and the plan.
 
-Artifact: `plan.md`, `checklist.md`, and at least one real `actions/ACTION_N.md`. At the S
-tier used here, the planner consolidates the whole delivery into a single
-`actions/ACTION_1.md` (the ordered steps plus the exact changes); the L tier (many
-independent tasks, dispatched in parallel) instead gets one `actions/ACTION_N.md` file per
-task. `checklist.md` follows a fixed form: tasks start under `## In Progress`, move to
+Artifact: `plan.md`, `checklist.md`, and at least one real `actions/ACTION_N.md`. A small
+delivery like this one consolidates the whole delivery into a single `actions/ACTION_1.md`
+(the ordered steps plus the exact changes); many independent tasks, dispatched in parallel,
+instead get one `actions/ACTION_N.md` file per task. `checklist.md` follows a fixed form: tasks start under `## In Progress`, move to
 `## Completed` as they land, and a `## Session Log` table records what happened each session.
 A task that depends on an owner decision landing first (a destructive step, a structural
 ruling) gets an `[ORCHESTRATOR]` prefix and blocks every other item until that decision is
@@ -86,7 +84,7 @@ Checkpoint: open `checklist.md`. Every task in `plan.md` has a matching checkbox
 `## In Progress`; that checklist, not `plan.md` itself, is what gets ticked off and moved to
 `## Completed` during Exec.
 
-### 6. Exec, verify before the gate
+### 6. Exec, verify before you report
 
 Type `/plastic-intent-executing`.
 
@@ -121,5 +119,5 @@ two, exactly the README section (or note) just delivered.
 
 That is the full cycle once: create, board, decide, spec, plan, build, done. Read
 [`your-first-intent-in-10-minutes.md`](https://github.com/zalom/plastic/blob/main/docs/guides/your-first-intent-in-10-minutes.md) for the same path condensed to a single
-read, and [`what-the-gates-are-telling-you.md`](https://github.com/zalom/plastic/blob/main/docs/guides/what-the-gates-are-telling-you.md) for what to do if a station denies
-an action instead of completing it.
+read, and [`reading-the-ledgers.md`](https://github.com/zalom/plastic/blob/main/docs/guides/reading-the-ledgers.md) for where each station wrote its
+work down.

package/skills/tutorial/references/track-2-auto.md

@@ -51,16 +51,15 @@ mixed up in what it tells you.
 
 Checkpoint: name one thing auto will always stop and ask about, rather than decide alone.
 
-### 3. Walking the gates
+### 3. Walking the record
 
-No new command. Auto still honors every hard gate a guided session would hit: the delivery
-lock (one owner at a time), the code gate (shut until `plan.md` and `checklist.md` exist),
-the create gate (intents only come from the tool that makes them, never hand-authored), the
-links gate (a `## Links` section changes only to match the file's own frontmatter), and the
-bash gate (a shell command cannot write project code the code gate would have blocked).
+No new command. Auto keeps one delivery in one place and writes down every move: the delivery
+lock (one owner at a time, a `delivery.lock` file in the intent directory), the worktree (code
+edits land on the intent's own branch), the savepoint ledger (one line per lifecycle file the
+team writes), and the day ledger (the request that started this run moves from pending to open
+when the first project file lands). Nothing blocks the team; the record is how you follow it.
 
-Checkpoint: read one gate message from the run so far and name which of the five gates it
-came from.
+Checkpoint: open the intent's `savepoint.md` and name the stage its last line records.
 
 ### 4. Reading the per-stage reports
 
@@ -75,7 +74,7 @@ line.
 
 ### 5. Continue and where-was-I after time away
 
-Type `/plastic-continuing`.
+Type `/plastic-intent-continuing`.
 
 Artifact: the current state, presented and then the session stops. If a specific intent is
 named, the agent reads its stage and savepoint and resumes exactly there, rather than
@@ -86,11 +85,11 @@ at and how that matched what was actually on disk.
 
 ## Wrap and where to go next
 
-Auto keeps the same stages and the same gates as guided; the only difference is who steers.
-Read [`pick-your-mode.md`](https://github.com/zalom/plastic/blob/main/docs/guides/pick-your-mode.md) for the honest trade-off between guided and auto, and
+Auto keeps the same stages and the same record as thinking; the only difference is who steers.
+Read [`pick-your-mode.md`](https://github.com/zalom/plastic/blob/main/docs/guides/pick-your-mode.md) for the honest trade-off between the three modes, and
 [`using-plastic-with-claude-code.md`](https://github.com/zalom/plastic/blob/main/docs/guides/using-plastic-with-claude-code.md) for how that choice feels day to day and how
-it connects to roadmap-driven delivery. For denial messages met along the way, read
-[`what-the-gates-are-telling-you.md`](https://github.com/zalom/plastic/blob/main/docs/guides/what-the-gates-are-telling-you.md).
+it connects to roadmap-driven delivery. For where the team wrote its work down, read
+[`reading-the-ledgers.md`](https://github.com/zalom/plastic/blob/main/docs/guides/reading-the-ledgers.md).
 
 Note on terms: "guided" means the user starts each stage with a command and the agent
 narrows the thinking inside it, the same shape track 1 walked. "Manual", editing project

package/skills/tutorial/references/track-3-projects-and-roadmaps.md

@@ -21,10 +21,10 @@ one this tutorial keeps or ships.
 ### 1. Start from a founding implementation intent
 
 Create and board an intent the same way as track 1, stations 1 and 2: `/plastic-intent-creating`,
-then `/plastic-intent-starting`. Describe something meant to grow into a small real project,
+then `/plastic-intent-continuing`. Describe something meant to grow into a small real project,
 for example "build a personal todo app."
 
-Then type `/plastic-intent-brainstorming` and record a couple of real rulings on this founding
+Then type `/plastic-intent-speccing` and record a couple of real rulings on this founding
 intent, for example the language or how tasks get stored. Keep it short: this intent only
 needs enough decisions for the new project to inherit, not a full design.
 

package/templates/agents.md

@@ -45,8 +45,8 @@ Active/Future/Completed placement is managed in INDEX.md, not in frontmatter.
 Create through the `plastic-intent-creating` skill, which scaffolds with one call:
 `ruby ~/.plastic/scripts/new-intent --store .plastic/store --intent "<one-line>" --slug <slug> [--sources <governing-id>]`.
 It allocates the Folgezettel ID, creates `.plastic/store/ID--slug/ID--slug.md` born
-complete, and wires the links. Never hand-author the files: the write-time create gate
-rejects an incomplete or malformed intent file.
+complete, and wires the links. Never hand-author the files: `new-intent` validates the
+intent file it writes, and `end-intent` checks it again at close.
 
 ## Lifecycle Skills
 
@@ -55,11 +55,8 @@ Plastic has its own lifecycle skills. When a Plastic skill exists for the curren
 | Phase | Skill | Produces |
 |-------|-------|----------|
 | What | `plastic-intent-creating` | Intent file |
-| Why | `plastic-intent-brainstorming` | Enriched `## Context` + `### Decisions` |
-| Why | `plastic-intent-speccing` | `spec.md` |
-| Why | `plastic-intent-researching` | `resources/*.md` |
-| Why | `plastic-intent-grilling` | Deep interrogation |
-| How | `plastic-intent-planning` | `plan.md`, `checklist.md`, `actions/` |
+| Why | `plastic-intent-speccing` | Rulings as insights, `resources/*.md`, `spec.md` |
+| How | `plastic-intent-speccing` | `actions/`, `plan.md`, `checklist.md` |
 | Exec | `plastic-intent-executing` | Code + `outcome.md` |
 | Done | `plastic-intent-ending` | Lifecycle transition |
 

package/templates/project.yml

@@ -3,3 +3,10 @@ governing_docs:
 
 release:
   on_complete: commit
+
+# flow:
+#   mode: direct               # direct | pull_request
+#   base: main                 # defaults to origin/HEAD, then main, then master
+#   branch_template: "session/{{day}}"   # {{day}}, {{ticket}}, {{slug}} tokens
+#   ticket_source: intent_id   # intent_id (the session pointer's intent id, else the day id)
+#   workspace: checkout        # checkout | worktree (worktree applies to direct mode only)

package/templates/roadmap.md

@@ -1,6 +1,6 @@
 # Roadmap: <name>
 
-(one-line meta: what this roadmap delivers, and which tier it lives in. `roadmaps/` is a sibling
+(one-line meta: what this roadmap delivers, and whether it is a project or the global roadmap. `roadmaps/` is a sibling
 of `INDEX.md` — a project's root or the global `~/.plastic/`, never inside `store/`. When this
 roadmap's goal is reached, move this file from `roadmaps/{slug}.md` to
 `roadmaps/archived/{slug}.md`; `roadmaps/` itself lists only live roadmaps.)

package/templates/savepoint.md

@@ -1,4 +1,4 @@
-# Deterministic cycle-step ledger, written automatically by the gate hook.
+# Deterministic cycle-step ledger, written automatically by the record hook.
 # One line per lifecycle milestone, append-only, newest at the bottom:
 #
 #   {UTC-iso8601}  {Stage}  {milestone}
@@ -11,4 +11,4 @@
 #   2026-06-16T16:40:00Z  Exec  outcome.md created
 #
 # This file is sugar on top of the conventions, not a source of truth. It is
-# rebuildable from files-on-disk via Bridge.rebuild_savepoint. Do not hand-edit.
+# rebuildable from files-on-disk via Savepoint.rebuild_savepoint. Do not hand-edit.

package/templates/session-intent.md

@@ -0,0 +1,29 @@
+---
+id: "{{DAY}}"
+intent: "Session ledger for {{DATE}}"
+sources: []
+chain: []
+created: {{CREATED}}
+author: {{AUTHOR}}
+tags: ["session"]
+mode: direct
+---
+
+## Intent
+Carry every session's activity for {{DATE}} in one shared, append-only day ledger.
+
+## Context
+This day ledger holds the checklist and savepoint lines that every session touching
+{{DATE}} appends, tagged by session and project. It is not a project intent: it has
+no plan, no actions, and no id that participates in a store's Folgezettel graph.
+
+## Outcome
+`checklist.md` and `savepoint.md` appear inside this day's directory on first append,
+each written under an exclusive file lock so concurrent sessions never lose or
+interleave a line.
+
+## Insights
+(observations captured throughout the day, appended by later sessions)
+
+## Links
+<!-- No sources or chain; this intent has no graph edges to project. -->