@zalom/plastic 1.0.0-beta.34 → 1.0.0-beta.36

package/skills/auto/references/end-tail.md

@@ -0,0 +1,56 @@
+# End-Tail Mechanics: resolve_session and Disarm Ordering
+
+Deep WHY/mechanics detail behind two spots in `SKILL.md`: how `arm_auto` resolves a
+session id when arming the gate, and why the End-tail steps in Completion (release
+worktrees, clear the lock, purge the bridge, reindex) run in that exact order.
+
+## Table of Contents
+
+- [resolve_session fallback internals](#resolve_session-fallback-internals)
+- [Disarm ordering and worktree cleanup rationale](#disarm-ordering-and-worktree-cleanup-rationale)
+- [QMD reindex ordering rationale](#qmd-reindex-ordering-rationale)
+
+## resolve_session fallback internals
+
+`arm_auto` calls `resolve_session`, which picks the first non-empty of: the explicit
+id you pass -> `CLAUDE_CODE_SESSION_ID` -> a deterministic derived key (a hash of the
+store and intent id). It never returns nil, so the gate engages even when every
+session env var is empty; the call never needs a non-empty session env var to
+function. Arming prints a one-line notice to stderr when it falls through to the
+derived key.
+
+Arming acquires the durable `delivery.lock` in the intent dir, keyed by that resolved
+session. Ownership is session-keyed, not process-keyed, so the arm one-liner exiting
+immediately is fine by construction: the lock stays yours for every later tool call in
+this session. A failed arm raises with a message naming the resolving `plastic-lock`
+verb.
+
+## Disarm ordering and worktree cleanup rationale
+
+Disarm runs the ordered End tail: it releases the worktrees first, then clears the
+intent's `delivery.lock` (and the bridge's lock cache), and only then is the bridge
+purge-eligible. Disarming also purges stale bridge files from the temp directory
+automatically (it keeps the current bridge, any live run, and any bridge whose intent
+still holds a delivery lock), so no manual `/tmp` cleanup is needed.
+
+**Worktree cleanup (mandatory, intent 73c3).** Disarming performs the worktree release:
+`disarm_auto` calls `Worktree.release`, which removes both per-intent worktrees (the code
+worktree under `<repo>/.claude/worktrees/{id}--{slug}` and the paired store worktree under
+`<plastic_home>/.worktrees/{id}--{slug}`), prunes both repos, and clears the worktree block
+from the bridge. This is the plain remove path: the disarm route does NOT merge, so use it
+only when no release merges the branch (the branch survives and can be reclaimed).
+
+When the work is being shipped through a release, do NOT rely on this plain remove. The
+release path (Completion step 4, via `plastic-releasing`) is responsible for merging the
+intent's code branch (`plastic/{id}--{slug}`) back to the repo's default branch BEFORE the
+worktree is removed, so the integrated work is not lost. It does this with
+`Worktree.finish(bridge_data, merge: true)` (merge-then-remove). Never leave an orphaned
+worktree, and run `git worktree prune` if you hit a stale reference.
+
+## QMD reindex ordering rationale
+
+Completion is the lifecycle event that keeps the search index fresh. `<store-root>` is
+the store that holds this intent (the global store or the project store). The reindex is
+the LAST End-tail step, run after purge, so the index never references a bridge or lock
+that is about to disappear (see PLASTIC.md `## Delivery Isolation and the Single-Owner
+Lock`).

package/skills/auto/references/human-report-contract.md

@@ -0,0 +1,55 @@
+# Human Report Contract (per-stage EM-to-CTO briefing)
+
+This doc defines how the orchestrator briefs the human at each of the five stage boundaries
+(What, Why, How, Exec, Done) in auto mode. It is the outward, human-facing counterpart to the
+internal report contract in `references/agent-report-contract.md`. Voice: an engineering
+manager briefing a CTO. Lead with impact, name the risk, leave the decision.
+
+## The skeleton
+
+One fixed 3-line shape, reused at every stage:
+
+1. **State**: what happened and what it means, impact first, one line.
+2. **Risk**: the one thing that could bite, or "nothing flagged."
+3. **Call**: the decision left to you, or the go-ahead I am taking.
+
+This is a shape, not a rigid template. Keep the order (State, then Risk, then Call) and keep it
+short. The words can flex to fit the stage.
+
+## Per-stage content
+
+- **What**: State = the work I picked up and why it matters now. Risk = scope uncertainty.
+  Call = confirm this is worth doing, or I proceed.
+- **Why**: State = the approach I chose, one line. Risk = the main trade-off. Call = the one
+  decision I need (approve, or pick an option).
+- **How**: State = the plan shape (task count and what it builds). Risk = the riskiest task or
+  dependency. Call = approve the plan to build.
+- **Exec**: State = what got built and the test result. Risk = residual failures or deviations.
+  Call = go to review, or done.
+- **Done**: State = the delivered impact. Risk = residual risk. Call = the decision left to you
+  (merge, release, accept).
+
+## Boundary vs intent 74
+
+Intent 74's report contract (`references/agent-report-contract.md`) is the INTERNAL,
+machine-checked handoff from a dispatched specialist back to the orchestrator: a structured
+envelope plus a per-role payload. This contract is the OUTWARD human briefing, orchestrator to
+user, in prose. Different direction, different audience, different form. The orchestrator
+CONSUMES the intent 74 report to WRITE the human briefing defined here. The two never merge.
+
+## Brevity: point, don't repeat
+
+Surface rules (no em-dashes, plain words, no filler openers, and so on) are owned by the
+shipped `plastic-humanizer` skill and the always-on plain-language layer. This contract does not
+re-list that catalog. It restates only the hard bans as one line: no em-dashes, no "not X but Y",
+no rule of three, no hype words, no sycophancy, no over-bolding. Apply `plastic-humanizer` and the
+always-on layer for everything else.
+
+## Emission: guided vs auto
+
+In guided mode, the briefing lands at each stage boundary and the human acts on the Call line
+before the next stage starts.
+
+In auto mode, the orchestrator still emits the briefing at each boundary, as a running EM-to-CTO
+account. The Call line becomes the go-ahead the orchestrator takes itself and moves on, except at
+the existing hard stops (destructive action without a safe alternative, project-path confirm).

package/skills/brainstorming/SKILL.md

@@ -44,30 +44,8 @@ You MUST create a task for each of these items and complete them in order:
 
 ## Process Flow
 
-```dot
-digraph brainstorming {
-    "Explore project context" [shape=box];
-    "Ask clarifying questions" [shape=box];
-    "Propose 2-3 approaches" [shape=box];
-    "Present design sections" [shape=box];
-    "User approves design?" [shape=diamond];
-    "Write spec" [shape=box];
-    "Spec self-review\n(fix inline)" [shape=box];
-    "User reviews spec?" [shape=diamond];
-    "Invoke plastic-writing-plans" [shape=doublecircle];
-
-    "Explore project context" -> "Ask clarifying questions";
-    "Ask clarifying questions" -> "Propose 2-3 approaches";
-    "Propose 2-3 approaches" -> "Present design sections";
-    "Present design sections" -> "User approves design?";
-    "User approves design?" -> "Present design sections" [label="no, revise"];
-    "User approves design?" -> "Write spec" [label="yes"];
-    "Write spec" -> "Spec self-review\n(fix inline)";
-    "Spec self-review\n(fix inline)" -> "User reviews spec?";
-    "User reviews spec?" -> "Write spec" [label="changes requested"];
-    "User reviews spec?" -> "Invoke plastic-writing-plans" [label="approved"];
-}
-```
+The Checklist above states the ordered flow (steps 1-8). For the same flow as a
+diagram, read `references/design-principles.md`.
 
 **The terminal state is invoking `plastic-writing-plans`.** Do NOT invoke any other implementation skill. The ONLY skill you invoke after brainstorming is `plastic-writing-plans`.
 
@@ -95,16 +73,11 @@ digraph brainstorming {
 - Cover: architecture, components, data flow, error handling, testing
 - Be ready to go back and clarify if something doesn't make sense
 
-**Design for isolation and clarity:**
-- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
-- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
-- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
-- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.
-
-**Working in existing codebases:**
-- Explore the current structure before proposing changes. Follow existing patterns.
-- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
-- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
+**Design for isolation and clarity, and working in existing codebases:** before
+proposing a design, read `references/design-principles.md` for unit-boundary
+guidance (what makes a good interface, when a file has grown too large) and
+existing-codebase guidance (follow established patterns, fold in targeted
+improvements without unrelated refactoring).
 
 ## After the Design
 **Documentation:**

package/skills/brainstorming/references/design-principles.md

@@ -0,0 +1,49 @@
+# Design Principles: Unit Boundaries and Existing Codebases
+
+General good-developer guidance behind two parts of the Process: how to design for
+isolation and clarity, and how to behave in an existing codebase. Also holds the
+Process Flow diagram (the same ordered flow the Checklist already states as numbered
+steps).
+
+## Design for isolation and clarity
+
+- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
+- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
+- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
+- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.
+
+## Working in existing codebases
+
+- Explore the current structure before proposing changes. Follow existing patterns.
+- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
+- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
+
+## Process Flow (diagram)
+
+The Checklist above already states this ordered flow as numbered steps 1-8; this
+diagram is the same flow in a visual form.
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write spec" [shape=box];
+    "Spec self-review\n(fix inline)" [shape=box];
+    "User reviews spec?" [shape=diamond];
+    "Invoke plastic-writing-plans" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write spec" [label="yes"];
+    "Write spec" -> "Spec self-review\n(fix inline)";
+    "Spec self-review\n(fix inline)" -> "User reviews spec?";
+    "User reviews spec?" -> "Write spec" [label="changes requested"];
+    "User reviews spec?" -> "Invoke plastic-writing-plans" [label="approved"];
+}
+```

package/skills/creating-intent/SKILL.md

@@ -124,32 +124,11 @@ cleanly, and do not work around the failure by hand-writing the files.
 
 ### 6. If Implementation Intent Spawns a Project
 
-When the user says "start building" or the plan calls for a new project:
-
-1. Determine project slug from intent name
-2. Create project directory in first `project_roots` path (from `~/.plastic/config.yml`):
-   ```bash
-   mkdir -p <project_root>/<slug>
-   cd <project_root>/<slug>
-   git init
-   ```
-3. Copy `AGENTS.md` template from `${CLAUDE_PLUGIN_ROOT}/templates/agents.md`
-4. Register in `~/.plastic/projects.yml`:
-   ```yaml
-   <slug>:
-     path: <full-path>
-     parent: "ID"
-     registered: <today>
-     status: active
-   ```
-5. Provision the project store (the single source of truth for store creation;
-   runs after step 4 because the provisioner requires the project to be
-   registered):
-   ```bash
-   ruby ~/.plastic/scripts/provision-project-store <slug>
-   ```
-6. Add `project-<slug>` to the intent's `tags` array
-7. Auto-commit in both `~/.plastic/` and the new project
+When the user says "start building" or the plan calls for a new project, invoke the
+`plastic-creating-project` skill; it owns project directory creation, AGENTS.md
+population, projects.yml registration, store provisioning, and the auto-commit of
+both stores. Add `project-<slug>` to this intent's `tags` array either before
+invoking it or as part of that skill's handoff.
 
 ### 7. Update INDEX.md
 

package/skills/creating-project/SKILL.md

@@ -43,89 +43,25 @@ Invoke `plastic-install --local` in the project directory. This creates:
 
 ### 4. Populate AGENTS.md
 
-Create `AGENTS.md` in the project root with:
-
-```markdown
-# <Project Name> — Agent Instructions
-
-Read `PLASTIC.md` in `~/.plastic/`. It contains all Plastic conventions.
-Follow it exactly.
-
-This file is the operating contract for this project. Any agent entering
-this project reads this file first.
-
-## Global Store
-
-Location: `~/.plastic/`
-Governing intent(s): <list of founding intent IDs with descriptions>
-
-## Decisions
-
-<Copy ALL decisions from founding intent(s)' `## Context > ### Decisions`>
-
-Each decision should include:
-- The decision itself
-- The rationale (why this choice)
-- Date decided
-
-## Project-Specific Rules
-
-<Any rules derived from the decisions — e.g., "Use Minitest, not RSpec",
-"37signals methodology", "sqlite-vec for vector storage">
-```
+Create `AGENTS.md` in the project root from the skeleton in
+`references/project-scaffolding.md` ("AGENTS.md skeleton"): read it now and fill in
+the project name, governing intent IDs, decisions, and project-specific rules.
 
 ### 5. Create Tactical Mirror
 
-Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`:
+Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`
+using the frontmatter, sections, and INDEX.md line in `references/project-scaffolding.md`
+("Tactical mirror intent"), including the Hub multi-intent variant if there is more
+than one founding intent.
 
 **Directory:** `~/.plastic/projects/{slug}/store/1--{slug}/`
 **File:** `~/.plastic/projects/{slug}/store/1--{slug}/1--{slug}.md`
 
-```yaml
----
-id: '1'
-intent: "<same description as founding intent>"
-sources: ["global:<founding_intent_ID>"]
-chain: []
-created: <today>
-author: <same as founding intent author>
-tags: [<relevant tags>]
----
-```
-
-Sections:
-- `## Intent` — same as founding intent
-- `## Context` — carry forward relevant Context and Decisions
-- `## Outcome` — (pending)
-- `## Insights` — empty
-- `## Links` — `[[global:<founding_intent_ID>|<founding intent name>]]`
-
-Update the project's `~/.plastic/projects/{slug}/INDEX.md`:
-```markdown
-# Index
-
-## Active
-- [1 — <intent name>](store/1--<slug>/1.md) — implementation, from: global:<ID>
-```
-
-**For multi-intent spawning (Hub):**
-- `sources`: `["global:<id1>", "global:<id2>", ...]` — all founding intents
-- All founding intents' decisions merge into AGENTS.md
-- Context carries forward from all founding intents
-
 ### 6. Register in projects.yml
 
-Read `~/.plastic/projects.yml` and add:
-
-```yaml
-<slug>:
-  path: <full-path>
-  parent: "<founding_intent_ID>"
-  registered: <today>
-  status: active
-```
-
-For Hub-spawned projects, `parent` references the primary founding intent.
+Read `~/.plastic/projects.yml` and add the entry shown in
+`references/project-scaffolding.md` ("projects.yml registration block"). For
+Hub-spawned projects, `parent` references the primary founding intent.
 
 ### 7. Provision the Project Store
 
@@ -195,4 +131,5 @@ Announce to user:
 
 ## References
 
+- Read `references/project-scaffolding.md` before steps 4-6, for the AGENTS.md skeleton, the tactical mirror intent format, and the projects.yml registration block
 - Read `references/hubs-projects.md` for the full hub/project relationship model, project creation flow, and cross-linking conventions

package/skills/creating-project/references/project-scaffolding.md

@@ -0,0 +1,97 @@
+# Project Scaffolding Templates
+
+Full templates for the artifacts created while spawning a project: the AGENTS.md
+skeleton (Workflow step 4), the tactical mirror intent (step 5), and the
+projects.yml registration block (step 6).
+
+## Table of Contents
+
+- [AGENTS.md skeleton (step 4)](#agentsmd-skeleton-step-4)
+- [Tactical mirror intent (step 5)](#tactical-mirror-intent-step-5)
+- [projects.yml registration block (step 6)](#projectsyml-registration-block-step-6)
+
+## AGENTS.md skeleton (step 4)
+
+Create `AGENTS.md` in the project root with:
+
+```markdown
+# <Project Name> — Agent Instructions
+
+Read `PLASTIC.md` in `~/.plastic/`. It contains all Plastic conventions.
+Follow it exactly.
+
+This file is the operating contract for this project. Any agent entering
+this project reads this file first.
+
+## Global Store
+
+Location: `~/.plastic/`
+Governing intent(s): <list of founding intent IDs with descriptions>
+
+## Decisions
+
+<Copy ALL decisions from founding intent(s)' `## Context > ### Decisions`>
+
+Each decision should include:
+- The decision itself
+- The rationale (why this choice)
+- Date decided
+
+## Project-Specific Rules
+
+<Any rules derived from the decisions — e.g., "Use Minitest, not RSpec",
+"37signals methodology", "sqlite-vec for vector storage">
+```
+
+## Tactical mirror intent (step 5)
+
+Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`:
+
+**Directory:** `~/.plastic/projects/{slug}/store/1--{slug}/`
+**File:** `~/.plastic/projects/{slug}/store/1--{slug}/1--{slug}.md`
+
+```yaml
+---
+id: '1'
+intent: "<same description as founding intent>"
+sources: ["global:<founding_intent_ID>"]
+chain: []
+created: <today>
+author: <same as founding intent author>
+tags: [<relevant tags>]
+---
+```
+
+Sections:
+- `## Intent` — same as founding intent
+- `## Context` — carry forward relevant Context and Decisions
+- `## Outcome` — (pending)
+- `## Insights` — empty
+- `## Links` — `[[global:<founding_intent_ID>|<founding intent name>]]`
+
+Update the project's `~/.plastic/projects/{slug}/INDEX.md`:
+```markdown
+# Index
+
+## Active
+- [1 — <intent name>](store/1--<slug>/1.md) — implementation, from: global:<ID>
+```
+
+**For multi-intent spawning (Hub):**
+- `sources`: `["global:<id1>", "global:<id2>", ...]` — all founding intents
+- All founding intents' decisions merge into AGENTS.md
+- Context carries forward from all founding intents
+
+## projects.yml registration block (step 6)
+
+Read `~/.plastic/projects.yml` and add:
+
+```yaml
+<slug>:
+  path: <full-path>
+  parent: "<founding_intent_ID>"
+  registered: <today>
+  status: active
+```
+
+For Hub-spawned projects, `parent` references the primary founding intent.

package/skills/dashboard/SKILL.md

@@ -110,23 +110,8 @@ a raw terminal. The Markdown board (`--data` + template) is the surface for the
 
 ## How classification works (deterministic)
 
-- **Effort** — small for `research`/`exploration`/`bugfix`, for already-scoped intents
-  (plan/checklist exists), or a **branch id** (folgezettel depth ≥ 2, e.g. `4a`, `12b3`); big
-  otherwise. A root id (a bare number) is always depth 1, so it is never demoted by this rule.
-- **Value → high** when any of: explicit `value: high`; a human-authored **root** intent; or
-  an intent that is a `source` of ≥1 other intent (it has spawned follow-on work). A purely
-  relational `chain` entry alone is **not** a value signal (intent 68) — else low.
-- **Flags** — `unblocked` only when a **future** intent has **all** its `sources` done AND at
-  least one source's completion date is strictly later than the intent's own `created` date (a
-  genuine wait, not a birth-time default); `in-progress` only when the savepoint ledger shows
-  real post-birth activity, not just the creation stamp; `stale` only on future intents past
-  the staleness threshold. All three kept low-noise by design.
-- **Override** — a `value: high|low` frontmatter field always wins (pre-stamped data, never
-  model judgment at render time).
-- **Caps** — quadrant lists and the project board's `active`/`future` lists are capped at 8
-  entries plus a trailing "+N more" line; each entry's text is truncated to 120 characters
-  with a trailing ellipsis. Applies to the Markdown board only (the ASCII renderer has its own
-  separate `CELL_CAP`).
+The script computes Effort/Value/Flags/Override/Caps; the agent never re-derives them.
+To explain or debug a quadrant assignment, read `references/classification.md`.
 
 ## Eval
 

package/skills/dashboard/references/classification.md

@@ -0,0 +1,22 @@
+# How Classification Works (Deterministic)
+
+The script (`dashboard.rb`) computes Effort/Value/Flags/Override/Caps deterministically;
+the agent never re-derives them. Read this to explain or debug a quadrant assignment.
+
+- **Effort** — small for `research`/`exploration`/`bugfix`, for already-scoped intents
+  (plan/checklist exists), or a **branch id** (folgezettel depth ≥ 2, e.g. `4a`, `12b3`); big
+  otherwise. A root id (a bare number) is always depth 1, so it is never demoted by this rule.
+- **Value → high** when any of: explicit `value: high`; a human-authored **root** intent; or
+  an intent that is a `source` of ≥1 other intent (it has spawned follow-on work). A purely
+  relational `chain` entry alone is **not** a value signal (intent 68) — else low.
+- **Flags** — `unblocked` only when a **future** intent has **all** its `sources` done AND at
+  least one source's completion date is strictly later than the intent's own `created` date (a
+  genuine wait, not a birth-time default); `in-progress` only when the savepoint ledger shows
+  real post-birth activity, not just the creation stamp; `stale` only on future intents past
+  the staleness threshold. All three kept low-noise by design.
+- **Override** — a `value: high|low` frontmatter field always wins (pre-stamped data, never
+  model judgment at render time).
+- **Caps** — quadrant lists and the project board's `active`/`future` lists are capped at 8
+  entries plus a trailing "+N more" line; each entry's text is truncated to 120 characters
+  with a trailing ellipsis. Applies to the Markdown board only (the ASCII renderer has its own
+  separate `CELL_CAP`).

package/skills/doctor/SKILL.md

@@ -3,7 +3,7 @@ name: plastic-doctor
 description: Use when diagnosing Plastic installation health, after updates, or when something seems broken. Runs checks and reports findings with fix options.
 ---
 
-# Doctor — Plastic Health Check
+# Doctor: Plastic Health Check
 
 ## Scopes
 
@@ -67,9 +67,9 @@ Parse the JSON output from stdout. The script is read-only and never modifies
 files. Errors go to stderr.
 
 Exit codes indicate check results, not script failure:
-- `0` — all checks passed
-- `1` — warnings found
-- `2` — failures found
+- `0`: all checks passed
+- `1`: warnings found
+- `2`: failures found
 
 All three exit codes mean the script ran successfully. Do not treat non-zero
 as an error.
@@ -118,7 +118,7 @@ Use the `fix_hint` value to determine the correct action:
 | "Remove stale references from INDEX.md" | Edit INDEX.md to remove ghost references |
 | "Inject the missing required frontmatter field(s)" | Edit the intent's `{ID}--{slug}.md` frontmatter to add the missing key (e.g. `chain: []`) without touching other keys |
 | "Run: provision-project-store {slug}" | Run `provision-project-store <slug>` (or invoke the `plastic-add-project-store` skill) to create the missing store |
-| "Re-run installer" | Run `npx @zalom/plastic@latest --agent` |
+| "Re-run installer" | Run `npx -y @zalom/plastic@<channel> install --agent <agent>` (channel: -alpha->@alpha, -beta->@beta, else @latest) |
 | "Dispatch plastic-intent-curator ... revisions.md ..." | Invoke the `plastic-intent-curator` (or the agent) to relocate the flagged section or ref into the intent's `revisions.md` via move-and-record (one dated, `[rule: <tag>]`-tagged entry per item), per PLASTIC.md > Structural maintenance and revisions.md. For a missing required section, restore or reproject it instead. |
 
 For fixes the agent cannot handle automatically, explain what the user needs
@@ -144,7 +144,7 @@ Show the updated results.
 When invoked from `plastic-update` (not directly by the user):
 
 1. Run the diagnostic script as in Step 1.
-2. If all checks pass: show a single line — **"Health check: all clear."**
+2. If all checks pass, show a single line: **"Health check: all clear."**
 3. If issues are found: show the full report (Steps 3-6).
 
 This keeps the update flow clean when nothing is wrong.