@zalom/plastic 1.0.3 → 1.1.1

package/PLASTIC-reference.md

@@ -115,19 +115,19 @@ Detailed conventions live inside the skills that use them, not in this file.
 
 | Topic | Skill | References in skill |
 |-------|-------|-------------------|
-| Creating intents, lifecycle | `plastic-creating-intent` | lifecycle, wikilinks |
-| Brainstorming, spec writing | `plastic-brainstorming` | — |
-| Planning, actions | `plastic-writing-plans` | — |
-| Execution, delivery | `plastic-executing-plan` | — |
+| Creating intents, lifecycle | `plastic-intent-creating` | lifecycle, wikilinks |
+| Brainstorming, spec writing | `plastic-intent-brainstorming` | — |
+| Planning, actions | `plastic-intent-planning` | — |
+| Execution, delivery | `plastic-intent-executing` | — |
 | Autonomous delivery | `plastic-auto` | agent architecture |
-| Save/restore state | `plastic-savepoint`, `plastic-continuing` | context management |
-| Knowledge graph, linking | `plastic-linking-intents` | zettelkasten, wikilinks |
-| Projects, hubs | `plastic-creating-project` | hubs, project stores |
-| Provision a project store | `plastic-add-project-store` | project stores |
-| Index maintenance | `plastic-managing-index` | — |
+| Save/restore state | `plastic-intent-savepoint`, `plastic-intent-continuing` | context management |
+| Knowledge graph, linking | `plastic-intent-linking` | zettelkasten, wikilinks |
+| Projects, hubs | `plastic-project-creating` | hubs, project stores |
+| Provision a project store | `plastic-store-provisioning` | project stores |
+| Index maintenance | `plastic-store-indexing` | — |
 | Releases, deprecations | `plastic-releasing` | deprecation process |
 | Health diagnostics | `plastic-doctor` | three scopes: `--core` (binary install-integrity check, runs on SessionStart), `--store [global\|<slug>]` (per-store check, runs on dashboard load), no flag = full check (runs after every update); gate enforcement, stuck detection |
-| Authoring skills, agents, hooks | `plastic-creating-skills` | progressive disclosure, agentskills.io spec |
-| Evaluating skills, evals | `plastic-evaluating-skills` | eval methodology, convention checks |
+| Authoring skills, agents, hooks | `plastic-skill-creating` | progressive disclosure, agentskills.io spec |
+| Evaluating skills, evals | `plastic-skill-evaluating` | eval methodology, convention checks |
 | Create, order, and consume a roadmap of intents | `plastic-roadmap` | file format, operations |
 

package/PLASTIC.md

@@ -93,10 +93,10 @@ tags: [plastic, architecture]
 
 | Stage | Section | Deliverable | Detail |
 |-------|---------|-------------|--------|
-| **What** | `## Intent` | `{ID}--{slug}.md` | `plastic-creating-intent` |
-| **Why** | `## Context` + Decisions | `spec.md` | `plastic-brainstorming` |
-| **How** | Planning | `plan.md` + `actions/` + `checklist.md` | `plastic-writing-plans` |
-| **Exec** | Execution | `outcome.md` | `plastic-executing-plan` |
+| **What** | `## Intent` | `{ID}--{slug}.md` | `plastic-intent-creating` |
+| **Why** | `## Context` + Decisions | `spec.md` | `plastic-intent-brainstorming` |
+| **How** | Planning | `plan.md` + `actions/` + `checklist.md` | `plastic-intent-planning` |
+| **Exec** | Execution | `outcome.md` | `plastic-intent-executing` |
 
 `## Insights` is the append-only log of durable discoveries captured throughout ALL stages.
 An insight is a discovery worth keeping for later reads: novel, or old but newly relevant,
@@ -167,8 +167,10 @@ and Exec, spins up the team above, and works the dashboard's dispatchable queue.
 `human_only` (intents that need a person); auto mode consumes the former.
 
 **Model contract.** Every agent in `agents/*.md` pins an explicit Claude Code model alias in
-its own frontmatter: `opus`, `sonnet`, or `haiku`. Never `inherit`, never Fable. Aliases track
-"latest per tier" so no Plastic release is required to advance a tier. The tier by role:
+its own frontmatter: `opus`, `sonnet`, or `haiku`. Never `inherit`, never Fable by default,
+unless an explicit `agents.models.<name>` config override names Fable for that role, in which
+case the override is honored as written. Aliases track "latest per tier" so no Plastic release
+is required to advance a tier. The tier by role:
 `plastic-enforcer`, `plastic-brainstorming`, `plastic-planner` are `opus`;
 `plastic-spec-specialist`, `plastic-executor`, `plastic-intent-curator`,
 `plastic-future-intent-researcher`, `plastic-intent-discovery` are `sonnet`.
@@ -237,7 +239,7 @@ Beyond the lifecycle agents, Plastic ships thin skills for day-to-day operation:
   for its three scopes (`--core` for the boot integrity check, `--store` per store on dashboard
   load, and the full no-flag walk after an update).
 - **Lifecycle skills** (`plastic-install`, `plastic-update`, `plastic-uninstall`,
-  `plastic-versions`, intent 55) are thin wrappers over a single pinned
+  `plastic-rollback`, intent 55) are thin wrappers over a single pinned
   `npx -y @zalom/plastic@<channel> <verb>` call: initialize or repair an install, advance a
   channel, remove Plastic, and step the local versions ledger.
 
@@ -327,7 +329,7 @@ A Zettelkasten structure note, not a table of contents. Clusters by meaning.
 
 Sections: `## Active`, `## Future`, `## Clusters`, `## Abandoned`, `## Completed`.
 
-For index maintenance, use `plastic-managing-index`.
+For index maintenance, use `plastic-store-indexing`.
 
 One-line entry convention. Each index entry is ONE line: `- [<id> <terse title>](<dir>) <tags>`.
 The title is the title, not a summary: aim for about 80 characters, no multi-sentence
@@ -350,7 +352,7 @@ ALL work flows through intents.
 3. On completion, capture observations in `## Insights`.
 4. When done, write `outcome.md` + `## Outcome` summary. Update INDEX.md.
 5. Researches are intents. No separate folder.
-6. Intents are created only via `plastic-creating-intent`. Never hand-author an intent file. The skill self-verifies the written intent with `scripts/validate-intent` before announcing or committing, so every intent is born complete. `--intent` text is escaped for double quotes and backslashes before it lands in frontmatter, so free-form text is safe to pass as-is, and a reciprocal `chain:` append preserves the target intent's existing flow- or block-style entries.
+6. Intents are created only via `plastic-intent-creating`. Never hand-author an intent file. The skill self-verifies the written intent with `scripts/validate-intent` before announcing or committing, so every intent is born complete. `--intent` text is escaped for double quotes and backslashes before it lands in frontmatter, so free-form text is safe to pass as-is, and a reciprocal `chain:` append preserves the target intent's existing flow- or block-style entries.
 
 ## House Style (self-check)
 

package/README.md

@@ -99,6 +99,53 @@ Plastic delivers all work through successive stages ->
 | How   | What is the plan?                               | Plan and checklist | plan.md, checklist.md, actions/ACTION_1.md ... ACTION_N.md |
 | Exec  | What was actually delivered?                    | Outcome            | outcome.md                                     |
 
+## How to use Plastic
+
+Plastic organizes all work as intents. Each intent is one directory, and it carries the same
+small set of files at every stage.
+
+**The intent directory**
+
+| File | What it holds |
+| ---- | -------------- |
+| `{id}--slug.md` | The intent itself: intent line, context, decisions |
+| `spec.md` | The Why, consolidated into one contract for the plan |
+| `plan.md`, `checklist.md`, `actions/` | The How: the plan and its execution registry |
+| `outcome.md` | The Exec record: what actually shipped |
+
+See [`docs/architecture.md`](docs/architecture.md) for the full store layout, and
+[reading a delivered intent](docs/guides/reading-a-delivered-intent.md) for how to read a
+finished one fast.
+
+**From idea to delivery, one line per stage**
+
+| Stage | What happens |
+| ----- | ------------- |
+| What | Describe the idea in plain words; Plastic scaffolds the intent |
+| Why | Explore it, one ruling at a time, then consolidate into `spec.md` |
+| How | Turn `spec.md` into `plan.md` and `checklist.md` |
+| Exec | Build the change, verify it, tick the checklist |
+| Done | `outcome.md` records what shipped; the index moves the intent to Completed |
+
+Walk this once in
+[your first intent in 10 minutes](docs/guides/your-first-intent-in-10-minutes.md), or run
+`plastic-tutorial` for an interactive, hands-on walkthrough of three different ways to work.
+
+**Commands, by family**
+
+| Family | Commands |
+| ------ | -------- |
+| Mode | `plastic-tutorial`, `plastic-auto` |
+| Intent | `plastic-continuing`, `plastic-intent-creating`, `plastic-intent-starting`, `plastic-intent-brainstorming`, `plastic-intent-grilling`, `plastic-intent-speccing`, `plastic-intent-planning`, `plastic-intent-executing`, `plastic-intent-ending`, `plastic-intent-continuing`, `plastic-intent-researching` |
+| Project and delivery | `plastic-project-creating`, `plastic-project-continuing`, `plastic-roadmap`, `plastic-roadmap-continuing`, `plastic-releasing` |
+| Skill | `plastic-skill-creating`, `plastic-skill-evaluating` |
+| Product | `plastic-install`, `plastic-update`, `plastic-uninstall`, `plastic-rollback`, `plastic-doctor`, `plastic-humanizer` |
+
+See [`docs/guides/index.md`](docs/guides/index.md) for task-oriented walkthroughs.
+
+The agent helps most at Why and How: turning a rough idea into rulings, and rulings into a
+plan a machine can build from exactly. Read
+[pick your mode](docs/guides/pick-your-mode.md) to decide how much of that to hand over.
 
 ## Compatibility and ownership
 
@@ -118,7 +165,7 @@ Plastic is developed through Plastic.
 The roadmap, intent history, plans, decisions, and outcomes
 behind releases are part of the repository, not a hidden process.
 
-See the current [roadmap](ROADMAP.md) and [changelog](CHANGELOG.md).
+[changelog](CHANGELOG.md).
 
 ## Documentation
 

package/agents/plastic-enforcer.md

@@ -12,7 +12,9 @@ You are the Plastic Enforcer. You ARE the auto orchestrator, spanning the whole
 orchestrating main session on the best available thinking model (Fable, Opus, or whatever
 supersedes them) for the sharpest gating and synthesis. This is advice only: it changes no
 behavior and blocks nothing if ignored. It concerns the human's MAIN session; dispatched
-subagents keep their pinned tier and never resolve to Fable.
+subagents keep their pinned tier and never resolve to Fable, unless an explicit
+`agents.models.<name>` config override names Fable for that role, in which case the override
+is honored as written.
 
 ## Your Responsibilities
 
@@ -42,7 +44,8 @@ dispatch also resolve the target agent's model through the config chain (`read-c
 agents.models.<basename> --project <repo>`: project override, then global, then the shipped
 tier default) and pass it explicitly as the dispatch call's model parameter, alongside the
 spawn-preamble live-state injection. Never rely on the dispatched role's frontmatter alone. A
-resolved subagent model is never Fable.
+resolved subagent model is never Fable, unless an explicit `agents.models.<name>` config
+override names Fable for that role, in which case the override is honored as written.
 5. **Gate each handoff** — check each stage deliverable against its exit criteria before handing to the next stage
 6. **Run the final review** — at the final gate, dispatch an INDEPENDENT reviewer subagent (not a sixth standing role)
 
@@ -56,7 +59,7 @@ ceremony, never these guarantees.
 1. Arm the gate, then dispatch the brainstorming specialist; gate its `## Context` + `### Decisions`
 2. Dispatch the spec-specialist; gate `spec.md`. Then the planner; gate `plan.md` + `checklist.md`
 3. Dispatch the executor; require a green suite. Sequential, one team per intent, on one branch when files are shared
-4. Dispatch and review by default through Plastic's native engine, `plastic-executing-plan` (implementer plus two-stage review, no external plugin). If `superpowers:subagent-driven-development` and `superpowers:dispatching-parallel-agents` are available, or the user asks for them, delegate to them as an enhancement
+4. Dispatch and review by default through Plastic's native engine, `plastic-intent-executing` (implementer plus two-stage review, no external plugin). If `superpowers:subagent-driven-development` and `superpowers:dispatching-parallel-agents` are available, or the user asks for them, delegate to them as an enhancement
 5. At the final gate, dispatch an independent reviewer subagent, then complete the intent
 
 ## Human-facing stage reporting
@@ -72,5 +75,5 @@ The orchestrator consumes that internal report to write the human briefing; the
 
 - Enforce gates manually; do not rely on hooks, because the session id may be unset in headless or background runs
 - You never delegate gate ownership; the orchestrator is always the gate-keeper
-- Roles are thin handoff contracts, not an execution engine; dispatch through `plastic-executing-plan` by default, and through the superpowers skills only when they are available or the user prefers them
-- Fall back by case: if the harness supports subagents but superpowers is absent, use the native `plastic-executing-plan` engine; if the harness has no subagent dispatch at all, fall back to a single agent walking the full cycle
+- Roles are thin handoff contracts, not an execution engine; dispatch through `plastic-intent-executing` by default, and through the superpowers skills only when they are available or the user prefers them
+- Fall back by case: if the harness supports subagents but superpowers is absent, use the native `plastic-intent-executing` engine; if the harness has no subagent dispatch at all, fall back to a single agent walking the full cycle

package/agents/plastic-future-intent-researcher.md

@@ -31,4 +31,4 @@ You are the Plastic Future Intent Researcher. Your role is to pick up parked fut
 - You never modify `## Insights` or `## Outcome` sections — those belong to the worker
 - You use Read, WebSearch, WebFetch, and Bash (read-only grep/find) for research
 - You never change status fields — status is convention-derived from INDEX.md placement
-- When dispatching any sub-agent, resolve its model via `read-config agents.models.<basename> --project <repo>` and pass it explicitly at dispatch, never relying on inherited frontmatter; a resolved subagent model is never Fable
+- When dispatching any sub-agent, resolve its model via `read-config agents.models.<basename> --project <repo>` and pass it explicitly at dispatch, never relying on inherited frontmatter; a resolved subagent model is never Fable, unless an explicit `agents.models.<name>` config override names Fable for that role, in which case the override is honored as written

package/agents/plastic-intent-curator.md

@@ -10,11 +10,11 @@ You are the Plastic Intent Curator. Your role is to maintain the health and navi
 
 ## Your Responsibilities
 
-1. **Intent lifecycle management** — move intents between Active/Future/Completed/Abandoned in INDEX.md, fill in `## Outcome` sections (including the abandonment rationale when an intent is abandoned)
-2. **INDEX.md maintenance** — keep Active/Future/Clusters/Completed/Abandoned sections accurate and well-organized
-3. **Link discovery** — suggest connections between intents that share topics but aren't linked
-4. **Cluster management** — create new clusters when 3+ unlinked intents share tags, merge or rename clusters as topics evolve
-5. **Orphan detection** — flag intents with no links and no cluster membership
+1. **Intent lifecycle management** - move intents between Active/Future/Completed/Abandoned in INDEX.md, fill in `## Outcome` sections (including the abandonment rationale when an intent is abandoned)
+2. **INDEX.md maintenance** - keep Active/Future/Clusters/Completed/Abandoned sections accurate and well-organized
+3. **Link discovery** - suggest connections between intents that share topics but aren't linked
+4. **Cluster management** - create new clusters when 3+ unlinked intents share tags, merge or rename clusters as topics evolve
+5. **Orphan detection** - flag intents with no links and no cluster membership
 6. **Structural maintenance** - relocate structural junk (an unsanctioned section, a stray file, a frontmatter edge to an intent that no longer exists) out of an intent and into that intent's `revisions.md`, without altering what the intent delivered
 
 ## How You Work
@@ -24,17 +24,16 @@ You are the Plastic Intent Curator. Your role is to maintain the health and navi
 2. Read `~/.plastic/INDEX.md` (or project INDEX.md) to understand current organization
 3. Compare: are there intents not in any cluster? Missing from Active/Completed/Abandoned? Status mismatches?
 4. Make targeted edits to INDEX.md and intent frontmatter/links
-5. On a terminal-state transition (Completed OR Abandoned), run the closing acts in the canonical End-tail order (see PLASTIC.md `## Delivery Isolation and the Single-Owner Lock`):
+5. On a terminal-state transition (Completed OR Abandoned), do these things:
    a. Author a real `outcome.md` in the intent directory from `~/.plastic/templates/outcome.md`, with the frontmatter `disposition: delivered` for a completed intent or `disposition: abandoned` for an abandoned one. `outcome.md` is MANDATORY at every terminal, delivered and abandoned alike: on abandon it records the abandonment reason and replaces the scaffolded placeholder sentinel (never leave `outcome.md` a placeholder at a terminal).
-   b. Stamp the terminal savepoint bookend (intent 81) recording the disposition. Idempotent.
-   c. Refresh the QMD index for that store LAST, after the terminal move, outcome.md, and savepoint, so the new outcome (or abandonment rationale) is searchable. This is mandatory on any terminal-state move and a no-op when QMD is absent, and it runs in the background so it never blocks: `ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async`
+   b. Call `plastic-intent-ending` for the terminal-transition close (INDEX move, savepoint `Done` bookend, store commit, disarm, and the QMD reindex last): `ruby ~/.plastic/scripts/end-intent --store <store> --id <id> --disposition delivered|abandoned`, then follow that skill's own disarm and reindex steps. Never restate the INDEX/savepoint/reindex one-liners here.
 6. Structural maintenance is move-and-record: remove the misplaced section, file, or ref from its artifact, then create or append `revisions.md` in that intent directory (copy the FORM from `~/.plastic/templates/revisions.md`). One entry per relocated item, newest at the bottom: a `## Revision vN - YYYY-MM-DD-HH:MM` header, a one-sentence `Why` ending with `[rule: <tag>]`, `Prior location`, and either `Content held` (verbatim) or a one-line `Change` for a frontmatter edit. For a stray file, embed its full content and delete the original. The violation-tag catalog is canonical in PLASTIC.md.
 7. Report what you changed
 
 ## Constraints
 
 - You only edit `~/.plastic/INDEX.md` (or project INDEX.md) and `~/.plastic/store/*/ID--slug.md` (or project store) files
-- You never create new intents — that's the creating-intent skill's job
-- You never modify `## Insights`, `## Context`, or `## Outcome` content sections — those belong to the worker. Relocating a whole misplaced block out of an intent and into `revisions.md` verbatim is structural maintenance, not authoring: maintenance moves an item out unchanged, it never rewords what stays, so the two rules do not conflict.
+- You never create new intents - that's the intent-creating skill's job
+- You never modify `## Insights`, `## Context`, or `## Outcome` content sections - those belong to the worker. Relocating a whole misplaced block out of an intent and into `revisions.md` verbatim is structural maintenance, not authoring: maintenance moves an item out unchanged, it never rewords what stays, so the two rules do not conflict.
 - For structural maintenance you may edit any Plastic artifact in an intent directory (intent file, `spec.md`, `plan.md`, `checklist.md`, `outcome.md`, frontmatter, or a stray file) and may create or append `revisions.md`. This is relocation only: you never rewrite, summarize, or reinterpret delivered content, and you never change what the intent delivered. A change to delivered meaning is a new intent, not a revision.
 - For discovery, put QMD first when available (`qmd-sync search`), then fall back to Read and grep/find; use Edit for targeted changes

package/agents/plastic-spec-specialist.md

@@ -12,18 +12,21 @@ When dispatched in auto mode you receive the standard Plastic spawn preamble (fr
 
 ## Your Responsibilities
 
-1. **Consolidate the Why** — turn the enriched `## Context` and `### Decisions` into one spec
-2. **Follow the template** — produce `spec.md` with Problem, Goals, Non-Goals, Approach, Decisions, Acceptance Criteria
-3. **Stamp the tier** — write a `Tier: S|M|L` line as the TOP line of spec.md, above the `#
+1. **Consolidate the Why**: turn the enriched `## Context` and `### Decisions` into one spec
+2. **Follow the template**: produce `spec.md` with all 8 sections in template order: Problem, Goals,
+   Non-Goals, Approach, Alternatives Considered, Decisions, Acceptance Criteria, Open Questions.
+   The shared fill method for each section is `skills/intent-speccing/references/per-section-fill-rules.md`;
+   read it when filling the template, it is the single owner of the method, do not fork it here.
+3. **Stamp the tier**: write a `Tier: S|M|L` line as the TOP line of spec.md, above the `#
    Spec:` heading, taking the value from the orchestrator's sizing / the brainstorming
    recommendation. This line is convention-only: read by the orchestrator, never validated by
    any gate or by doctor. It is an extra top line, not a template field, so no template changes.
-4. **Accept collapsed sections at S/M** — a spec.md whose Problem, Goals, Non-Goals, Approach,
+4. **Accept collapsed sections at S/M**: a spec.md whose Problem, Goals, Non-Goals, Approach,
    Decisions, or Acceptance Criteria sections are a single line each is still a complete
    spec.md under the same-structure invariant; do not pad it. The gates check file existence
    and realness, not artifact depth, so a collapsed-but-real spec passes.
-5. **Make it the contract** — the spec is what the planner and executor build against
-6. **Hand off** — leave a complete `spec.md` ready for the planner
+5. **Make it the contract**: the spec is what the planner and executor build against
+6. **Hand off**: leave a complete `spec.md` ready for the planner
 
 ## How You Work
 

package/bin/plastic.js

@@ -6,7 +6,7 @@
 //   npx @zalom/plastic install   [flags]
 //   npx @zalom/plastic update    [flags]
 //   npx @zalom/plastic uninstall [flags]
-//   npx @zalom/plastic versions  [flags]
+//   npx @zalom/plastic rollback  [flags]
 //
 // Back-compat: a bare `--uninstall` (no subcommand) routes to uninstall with a deprecation
 // warning; no subcommand at all defaults to install (legacy behaviour, one release).
@@ -15,7 +15,7 @@ import { execFileSync } from 'node:child_process'
 import { resolve } from 'node:path'
 import { existsSync } from 'node:fs'
 
-const VERBS = ['install', 'update', 'uninstall', 'versions']
+const VERBS = ['install', 'update', 'uninstall', 'rollback']
 const packageRoot = new URL('..', import.meta.url).pathname
 const argv = process.argv.slice(2)
 

package/hooks/check-update

@@ -5,7 +5,7 @@
 # upgrade target instead of blindly trusting the `latest` tag.
 
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-PLASTIC_HOME="$HOME/.plastic"
+PLASTIC_HOME="${PLASTIC_HOME:-$HOME/.plastic}"
 CACHE_DIR="$PLASTIC_HOME/.cache"
 CACHE_FILE="$CACHE_DIR/update-check.json"
 VERSION_FILE="$PLASTIC_HOME/VERSION"

package/hooks/continue

@@ -23,7 +23,7 @@ if echo "$MESSAGE" | grep -iq '\bcontinue\b'; then
 {
   "hookSpecificOutput": {
     "hookEventName": "UserPromptSubmit",
-    "additionalContext": "PLASTIC CONTINUE — The user wants to resume previous work.\n\nRead ~/.plastic/INDEX.md and follow the continuing skill workflow."
+    "additionalContext": "PLASTIC CONTINUE: The user wants to resume previous work.\n\nRead ~/.plastic/INDEX.md and follow the plastic-continuing skill workflow."
   }
 }
 HOOKJSON

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zalom/plastic",
-  "version": "1.0.3",
+  "version": "1.1.1",
   "description": "Intent-driven idea development system for AI coding agents",
   "type": "module",
   "bin": {

package/scripts/dashboard.rb

@@ -33,7 +33,7 @@ def today
 end
 
 # A generic "about a month" threshold, not tuned to any one store's item count.
-# Deliberately independent from plastic-continuing's separate stale_threshold_days
+# Deliberately independent from plastic-project-continuing's separate stale_threshold_days
 # config: that one is a proactive boot-time triage nudge, this is a board annotation.
 # Unifying the two is a follow-up, not this intent.
 STALE_DAYS = 30
@@ -355,10 +355,7 @@ LIFECYCLE_GLYPH = { "what" => "○", "why" => "◔", "how" => "◑", "exec" => "
 DISPOSITION_GLYPH = { "drive" => "▸", "defer" => "⇢", "research" => "⊙", "triage" => "⚑" }.freeze
 LEGEND = "legend  ○ What ◔ Why ◑ How ◕ Exec ● Done │ ▸drive ⇢defer ⊙research ⚑triage │ ⇡unblocked"
 
-# Markdown board glyphs (intent 37). Quadrant signatures + per-line bullets.
-QUADRANT_BULLET = {
-  "quick_win" => "⚡", "next_big" => "★", "defer" => "→", "triage" => "⚑",
-}.freeze
+# Markdown board glyphs (intent 37). Status signature for the project active/future lists.
 STATUS_GLYPH = { "active" => "◑", "completed" => "●", "future" => "○" }.freeze
 
 # ---------------------------------------------------------------------------
@@ -375,10 +372,10 @@ end
 CELL_CAP = 6
 
 # Markdown-board caps (Task 5, D6/D7): the ASCII renderer already caps via CELL_CAP/
-# cap_cell, but the Markdown board's matrix_data quadrants and the project board's
+# cap_cell, but the Markdown board's next_work list and the project board's
 # active/future lists had no cap and no per-line truncation, so a large store printed
 # hundreds of full-length lines. These two constants fix that on the Markdown side only.
-MATRIX_DATA_CAP = 8
+NEXT_WORK_CAP = 8
 INTENT_LINE_MAX_CHARS = 120
 
 def matrix(records, scope_tag: false)
@@ -584,31 +581,39 @@ def intent_line(rec, bullet)
     scope: rec[:scope], line: "#{bullet} #{rec[:id]} #{text}#{note}".rstrip }
 end
 
-# Cap a raw record list to MATRIX_DATA_CAP entries, then map to intent_line-shaped
+# Cap a raw record list to NEXT_WORK_CAP entries, then map to intent_line-shaped
 # hashes, appending a plain "+N more" line (no id, not a real record) when truncated.
 # Caps the record list first so the "+N more" entry never goes through intent_line.
 def cap_lines(list, bullet)
-  capped = list.first(MATRIX_DATA_CAP)
+  capped = list.first(NEXT_WORK_CAP)
   lines = capped.map { |r| intent_line(r, bullet) }
-  if list.size > MATRIX_DATA_CAP
+  if list.size > NEXT_WORK_CAP
     lines << { id: "", intent: "", created: "", bullet: bullet, scope: "",
-               line: "#{bullet} +#{list.size - MATRIX_DATA_CAP} more" }
+               line: "#{bullet} +#{list.size - NEXT_WORK_CAP} more" }
   end
   lines
 end
 
-def matrix_data(records)
-  cells = { "quick_win" => [], "next_big" => [], "defer" => [], "triage" => [] }
-  research = []
-  records.each do |r|
-    if %w[research exploration].include?(r[:type]) then research << r
-    else cells[r[:quadrant]] << r end
+# Flat, rank-ordered "most-valuable next work" list (intent 149). Replaces the
+# quadrant-keyed matrix_data with a single list ranked by the same rank_key every
+# other ordering uses, capped at NEXT_WORK_CAP with a trailing "+N more" marker
+# when the pool overflows. No grid glyph on the line; the prose surface supplies
+# its own bullet.
+def next_work(records)
+  ranked = records.sort_by { |r| rank_key(r) }
+  capped = ranked.first(NEXT_WORK_CAP)
+  lines = capped.map do |r|
+    text = r[:intent].to_s
+    text = "#{text[0, INTENT_LINE_MAX_CHARS]}…" if text.length > INTENT_LINE_MAX_CHARS
+    { id: r[:id], intent: r[:intent], scope: r[:scope], lifecycle: r[:lifecycle],
+      value: r[:value].to_s, disposition: r[:disposition], flags: r[:flags],
+      line: "#{r[:id]} #{text}" }
   end
-  by_created_desc = ->(list) { list.sort_by { |r| invert_ts(r[:created]) } }
-  out = {}
-  cells.each { |q, list| out[q] = cap_lines(by_created_desc.call(list), QUADRANT_BULLET[q]) }
-  out["research"] = cap_lines(by_created_desc.call(research), "🔬")
-  out
+  if ranked.size > NEXT_WORK_CAP
+    lines << { id: "", intent: "", scope: "", lifecycle: "", value: "", disposition: "",
+               flags: [], line: "+#{ranked.size - NEXT_WORK_CAP} more" }
+  end
+  lines
 end
 
 def short_description(scope)
@@ -654,7 +659,7 @@ def render_data_global(records)
   { mode: "global", date: today.to_s,
     store_health: store_health(:global),
     recently_worked: recently_worked(records),
-    matrix: matrix_data(matrix_pool),
+    next_work: next_work(matrix_pool),
     counts: counts_of(global),
     projects: projs,
     project_totals: {
@@ -671,7 +676,7 @@ def render_data_project(records, slug)
     store_health: store_health(slug),
     description: short_description(scope),
     recently_worked: recently_worked(records, project_scope: scope),
-    matrix: matrix_data(matrix_pool),
+    next_work: next_work(matrix_pool),
     counts: counts_of(scoped),
     active: cap_lines(scoped.select { |r| r[:status] == "active" }
                             .sort_by { |r| invert_ts(r[:last_accessed_at]) }, STATUS_GLYPH["active"]),