@zalom/plastic 1.0.0-beta.32 → 1.0.0-beta.33

package/PLASTIC.md

@@ -329,10 +329,12 @@ is a named, ordered, delivery-side collection of intents: the delivery-side coun
 release (completion-side, tracked in `CHANGELOG.md`). Use `plastic-roadmap` to create, order,
 close, and consume one.
 
-File location: `roadmaps/{slug}.md`, a store-root sibling of `INDEX.md`, identical in the global
-store (`~/.plastic/store/`) and any project store (`~/.plastic/projects/{slug}/store/`).
-`roadmaps/` lists only live (open or in-flight) roadmaps: once a roadmap's goal is reached, it
-moves to `roadmaps/archived/{slug}.md`, a sibling subdirectory scaffolded once with a `.gitkeep`.
+File location: `roadmaps/{slug}.md`, a sibling of `INDEX.md`, wherever `INDEX.md` lives, never
+inside `store/` (store holds intent directories, not project artifacts). For a project that is its
+root, `~/.plastic/projects/{slug}/roadmaps/`, beside `project.yml`; for the global tier it is
+`~/.plastic/roadmaps/`, beside `~/.plastic/INDEX.md`. `roadmaps/` lists only live (open or
+in-flight) roadmaps: once a roadmap's goal is reached, it moves to `roadmaps/archived/{slug}.md`,
+a sibling subdirectory scaffolded once with a `.gitkeep`.
 
 A roadmap file has four sections, in order: a title/meta header, `## Goal`, `## Waves`, and an
 append-only dated `## Log`. `## Goal` is a checkable prose condition read by a human or agent, not
@@ -345,8 +347,9 @@ on any conflict INDEX wins and the roadmap entry is corrected to match.
 
 **Human-comprehension surface.** A roadmap is also written to be read cold. Wave entries render as
 checkboxes (checked once delivered, unchecked otherwise) next to the status token, and each `## Log`
-line is one plain-language sentence, dated, written the way an engineering manager would brief a
-non-expert executive: what shipped and why it matters, no jargon or codenames, ending with a link
+line is one plain-language sentence, starting `YYYY-MM-DD HH:MM UTC`, written the way an
+engineering manager would brief a non-expert executive: what shipped and why it matters, no jargon
+or codenames, ending with a link
 to that intent's `outcome.md`. The log points at the detail instead of repeating it, so a person
 opening the file with no other context can tell what shipped, what is running now, and what is
 next in under a minute.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zalom/plastic",
-  "version": "1.0.0-beta.32",
+  "version": "1.0.0-beta.33",
   "description": "Intent-driven idea development system for AI coding agents",
   "type": "module",
   "bin": {

package/scripts/update.rb

@@ -53,18 +53,22 @@ class Update < InstallerCore
       end
       puts "\u{2b06}\u{fe0f}  Updating Plastic #{iv} \u{2192} #{res[:target]}"
       exit_code = perform_switch(res[:target], agent_args(argv))
-      run_post_update_doctor if exit_code == 0
+      run_post_update_doctor(full: argv.include?("--full-doctor")) if exit_code == 0
       exit_code
     end
   end
 
-  # Run the full doctor after a successful update and print a human-readable
-  # summary. Informational only: does not raise and does not affect the update's
-  # exit code. Accepts injected `doctor` and `out` for hermetic unit tests.
-  def run_post_update_doctor(doctor: nil, out: $stdout)
+  # Run doctor after a successful update and print a human-readable summary.
+  # Defaults to the fast core tier (agent registration + core files + manifest
+  # sync, binary pass|fail, no store walk) so a newcomer's first post-update
+  # run is not buried in convention warns they cannot act on. `full: true`
+  # (via `--full-doctor`) runs the complete store walk instead. Informational
+  # only: does not raise and does not affect the update's exit code. Accepts
+  # injected `doctor` and `out` for hermetic unit tests.
+  def run_post_update_doctor(doctor: nil, out: $stdout, full: false)
     doctor ||= Doctor.new
-    out.puts "\nRunning full doctor after update..."
-    result = doctor.run_checks("claude")
+    out.puts full ? "\nRunning full doctor after update..." : "\nRunning core doctor after update..."
+    result = full ? doctor.run_checks("claude") : doctor.run_core_checks("claude")
     s = result[:summary]
     out.puts "  Doctor status: #{result[:status]} " \
              "(pass: #{s[:pass]}, warn: #{s[:warn]}, fail: #{s[:fail]}, total: #{s[:total]})"
@@ -152,6 +156,11 @@ class Update < InstallerCore
       Agent options (default: --claude):
         --claude --codex --hermes --all
 
+      Post-update doctor:
+        By default, a successful update runs the fast core doctor sync (agent
+        registration, core files, manifest — binary pass|fail, no store walk).
+        --full-doctor   Run the full doctor (complete store walk) after updating.
+
       Behaviour:
         No flag advances to the next version on your current channel. Switching toward a
         more stable channel is frictionless; switching toward bleeding edge is confirmed.

package/skills/roadmap/SKILL.md

@@ -6,9 +6,11 @@ description: Use when the user wants to plan a delivery batch, order waves of in
 # Roadmap
 
 A roadmap is a named, ordered, delivery-side collection of intents: the delivery-side counterpart
-to a release (completion-side, `CHANGELOG.md`). It lives at `roadmaps/{slug}.md`, a store-root
-sibling of `INDEX.md`, in both the global store (`~/.plastic/store/`) and any project store
-(`~/.plastic/projects/{slug}/store/`).
+to a release (completion-side, `CHANGELOG.md`). It lives at `roadmaps/{slug}.md`, a sibling of
+`INDEX.md` wherever `INDEX.md` lives: the global tier's `~/.plastic/roadmaps/` (beside
+`~/.plastic/INDEX.md`), or a project's root, `~/.plastic/projects/{slug}/roadmaps/` (beside that
+project's `INDEX.md` and `project.yml`). It never sits inside `store/`, which holds intent
+directories, not project artifacts.
 
 A roadmap file has four parts: a title/meta header, `## Goal` (prose), `## Waves` (ordered; entries
 inside a wave are parallel-safe, waves run sequentially), and an append-only dated `## Log`. Each
@@ -37,8 +39,9 @@ verb above.
 
 ## Notes
 
-- File location and the four-section shape are identical across stores; do not invent a different
-  layout per project.
+- File location and the four-section shape are identical across tiers; do not invent a different
+  layout per project. The general rule: `roadmaps/` is a sibling of `INDEX.md`, wherever `INDEX.md`
+  lives.
 - `## Goal` is a checkable prose condition read by a human or agent, not an executable checker.
 - Wave entries render as checkboxes (`- [x] ... — delivered` / `- [ ] ... — <status>`); a human
   reading cold should see shipped/running/next within a minute. `## Log` lines are one-sentence,

package/skills/roadmap/references/file-format.md

@@ -2,10 +2,12 @@
 
 ## Location
 
-`roadmaps/{slug}.md`, a store-root sibling of `INDEX.md`. Same layout in the global store
-(`~/.plastic/store/roadmaps/{slug}.md`) and any project store
-(`~/.plastic/projects/{slug}/store/roadmaps/{slug}.md`). Create the `roadmaps/` directory the
-first time a store gets a roadmap.
+`roadmaps/{slug}.md`, a sibling of `INDEX.md`, wherever `INDEX.md` lives. For the global tier
+that is `~/.plastic/roadmaps/{slug}.md` (beside `~/.plastic/INDEX.md`); for any project it is
+that project's root, `~/.plastic/projects/{slug}/roadmaps/{slug}.md` (beside that project's
+`INDEX.md` and `project.yml`). `roadmaps/` never sits inside `store/`: `store/` holds intent
+directories, not project artifacts. Create the `roadmaps/` directory the first time a tier gets a
+roadmap.
 
 `roadmaps/` lists only live (open or in-flight) roadmaps. Once a roadmap's `## Goal` is reached,
 its file moves to `roadmaps/archived/{slug}.md` (see Close/archive in `operations.md`); the
@@ -14,7 +16,7 @@ its file moves to `roadmaps/archived/{slug}.md` (see Close/archive in `operation
 ## The four sections (in order)
 
 1. **Title/meta header** — `# Roadmap: <name>` plus a one-line meta sentence naming what the
-   roadmap delivers and which store it lives in.
+   roadmap delivers and which tier (project or global) it lives in.
 2. **`## Goal`** — a checkable prose condition: one or a few sentences a human or coordinator reads
    to decide the roadmap is done. Not an executable checker, not a list of tasks.
 3. **`## Waves`** — ordered waves (`### Wave 1`, `### Wave 2`, ...). Entries inside a wave are
@@ -49,12 +51,13 @@ it. The roadmap never sets a status that INDEX does not already reflect.
 
 ## Log line shape
 
-One line per event, dated, in plain-language EM-to-CTO voice: what shipped and why it matters to a
-non-expert reader, no jargon or internal codenames, ending with a link to that entry-intent's
-`outcome.md`:
+One line per event, starting `YYYY-MM-DD HH:MM UTC` (human-readable, sortable, zone-explicit so
+same-day parallel deliveries can still be ordered), in plain-language EM-to-CTO voice: what shipped
+and why it matters to a non-expert reader, no jargon or internal codenames, ending with a link to
+that entry-intent's `outcome.md`:
 
 ```
-- <YYYY-MM-DD> <one plain-language sentence: what shipped, its impact> — see store/<id>--<slug>/outcome.md
+- <YYYY-MM-DD HH:MM UTC> <one plain-language sentence: what shipped, its impact> — see store/<id>--<slug>/outcome.md
 ```
 
 The log line never restates `outcome.md` detail; it points at it (lossless-by-reference). This
@@ -83,6 +86,6 @@ abandoned | blocked); INDEX wins on any conflict.
 - [x] 124 Roadmap feature — delivered
 
 ## Log
-- 2026-07-06 Shipped the bash-gate redirect fix so quoted arrows and heredoc trailers stop
-  blocking legitimate commits — see store/121--fix-bash-gate-redirect-parsing/outcome.md.
+- 2026-07-06 14:32 UTC Shipped the bash-gate redirect fix so quoted arrows and heredoc trailers
+  stop blocking legitimate commits — see store/121--fix-bash-gate-redirect-parsing/outcome.md.
 ```

package/skills/roadmap/references/operations.md

@@ -10,14 +10,16 @@ next" in under a minute, just from this one file.
 ## Create
 
 1. Pick a `slug` (kebab-case, descriptive) and a `title`.
-2. Resolve the store root (global `~/.plastic/store/` or the current project's
-   `~/.plastic/projects/{slug}/store/`); create `roadmaps/` inside it if it does not exist yet.
+2. Resolve the tier root: the directory that holds `INDEX.md` (a project's root, beside
+   `project.yml`, or `~/.plastic/` for the global tier). `roadmaps/` is always a sibling of
+   `INDEX.md`, never inside `store/`. Create `roadmaps/` there if it does not exist yet.
 3. Copy `templates/roadmap.md` to `roadmaps/{slug}.md`.
 4. Fill the header (`# Roadmap: <title>` + the one-line meta) and write a real `## Goal` prose
    condition.
 5. Add at least one `## Waves` wave with real entries (see Add / reorder below), each entry's
    status mirroring that intent's current `INDEX.md` status.
-6. Append the first `## Log` line, a short dated plain-language note that the roadmap was created.
+6. Append the first `## Log` line, a short `YYYY-MM-DD HH:MM UTC`-prefixed plain-language note
+   that the roadmap was created.
 
 ## Add / reorder entries
 
@@ -29,7 +31,7 @@ next" in under a minute, just from this one file.
   entries) earlier or later. Reordering never changes an entry's status; it only changes when the
   entry is eligible to run.
 - After any add/reorder, append a `## Log` line describing the change (e.g.
-  `- <YYYY-MM-DD> added 132 to wave 2`).
+  `- <YYYY-MM-DD HH:MM UTC> added 132 to wave 2`).
 
 ## Sync status mirror
 
@@ -46,8 +48,8 @@ next" in under a minute, just from this one file.
 
 ## Append a log line
 
-- One line per event, dated `YYYY-MM-DD`, appended at the bottom of `## Log`. Never edit or delete
-  an existing line (append-only).
+- One line per event, starting `YYYY-MM-DD HH:MM UTC`, appended at the bottom of `## Log`. Never
+  edit or delete an existing line (append-only).
 - Every line is plain language a non-expert can read, never a codename or a raw `field -> value`.
   A delivery event follows the EM-to-CTO one-line shape with an `outcome.md` link (see
   `file-format.md`); bookkeeping events (created, an intent added to a wave, a wave completed, a
@@ -68,7 +70,9 @@ next" in under a minute, just from this one file.
 
 1. Confirm the roadmap's `## Goal` prose condition is met (every entry `delivered` or explicitly
    `abandoned` with a recorded reason, plus whatever else the goal states).
-2. Create `roadmaps/archived/` in the store root if it does not exist yet.
+2. Create `roadmaps/archived/` beside `roadmaps/` (both siblings of `INDEX.md`) if it does not
+   exist yet.
 3. Move the file: `roadmaps/{slug}.md` -> `roadmaps/archived/{slug}.md`. `roadmaps/` itself then
    lists only live (open or in-flight) roadmaps.
-4. Append the final `## Log` line before or as part of the move: `- <YYYY-MM-DD> roadmap closed`.
+4. Append the final `## Log` line before or as part of the move:
+   `- <YYYY-MM-DD HH:MM UTC> roadmap closed`.

package/templates/roadmap.md

@@ -1,8 +1,9 @@
 # Roadmap: <name>
 
-(one-line meta: what this roadmap delivers, and which store it lives in. 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.)
+(one-line meta: what this roadmap delivers, and which tier it lives in. `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.)
 
 ## Goal
 (a checkable prose condition — one or a few sentences a human or coordinator reads to decide the
@@ -26,4 +27,4 @@ any conflict between the checkbox/token here and INDEX's real status.
 what shipped and its impact for a non-expert reader, no jargon or internal codenames, ending with a
 link to that entry-intent's `outcome.md`. Never restate outcome detail here; link to it instead.
 Newest at the bottom.)
-- 2026-01-01 Shipped the first wave of this roadmap; see store/<intent-id>--<slug>/outcome.md.
+- 2026-01-01 00:00 UTC Shipped the first wave of this roadmap; see store/<intent-id>--<slug>/outcome.md.