@benzotti/jedi 0.1.42 → 0.1.45

package/framework/components/meta/SilentDiscovery.md

@@ -0,0 +1,79 @@
+# SilentDiscovery Component
+
+The mandatory state-reading preamble that runs before any user-facing prompt in a JDI skill. Its purpose: make sure you never re-ask the user for facts that are already on disk.
+
+When a command references `<JDI:SilentDiscovery />`, you MUST gather context from the filesystem before presenting any question, routing decision, or recommendation. Store what you find internally as `DISCOVERED_STATE` — do NOT print discovery output to the user unless a later step explicitly calls for it.
+
+---
+
+## What to Read
+
+Read these files if they exist. If a file is missing, record that in `DISCOVERED_STATE` as `missing: true` and continue — do not error.
+
+| File | Purpose |
+|------|---------|
+| `.jdi/config/state.yaml` | Current phase, plan, task, and status. Source of truth for "where are we?" |
+| `.jdi/PROJECT.yaml` | Tech stack, project name, team configuration |
+| `.jdi/REQUIREMENTS.yaml` | Risks, constraints, non-functional requirements |
+| `.jdi/ROADMAP.yaml` | Phase structure, upcoming plans, milestones |
+| `.jdi/plans/*.plan.md` (glob) | Existing plan index files — check frontmatter for `provides`, `status`, completion |
+| `.jdi/codebase/SUMMARY.md` | Codebase index, if present |
+
+Additionally, if the skill is worktree-aware, read:
+
+| File | Purpose |
+|------|---------|
+| `.jdi/config/state.yaml → worktree` | Active worktree path and status |
+
+---
+
+## What to Derive
+
+From the raw reads above, compute and store these derived fields in `DISCOVERED_STATE`:
+
+- **`active_phase`** — current phase number and name (from ROADMAP.yaml + state.yaml position)
+- **`next_plan_number`** — next available plan id in the active phase (scan existing plan files)
+- **`tech_stack`** — from PROJECT.yaml
+- **`open_risks`** — from REQUIREMENTS.yaml `risks:` block (empty list if none)
+- **`prior_provides`** — union of all `provides:` fields from completed plans (cross-phase dependency map)
+- **`returning_user`** — true if any prior plans are completed or the current plan is in a non-initial status
+- **`missing_scaffolding`** — list of scaffolding files that didn't exist
+
+---
+
+## Discipline Rules
+
+These rules are non-negotiable when this component is referenced:
+
+1. **Silent by default.** Never print `DISCOVERED_STATE` as a conversation opener. It informs your recommendations; it is not the first thing the user sees.
+
+2. **Never re-ask what's already known.** If a fact is in `DISCOVERED_STATE`, treat it as authoritative. Do not ask "what's your tech stack?" if `DISCOVERED_STATE.tech_stack` is set.
+
+3. **Missing ≠ empty.** A missing file means "I don't know" — not "the user has no preferences". Record `missing: true` and surface it only if a later step needs that file.
+
+4. **Surface selectively.** When routing or recommending, pull the specific field you need and mention it briefly ("I can see you're on phase {n}, plan {id}..."). Do not dump the whole `DISCOVERED_STATE` object.
+
+5. **Refresh, don't stale.** If the skill has multiple passes (e.g. `/jdi:build` option D re-runs discovery after user input), re-read the files — do not rely on the first pass's findings for the second pass.
+
+---
+
+## Pass-Through to Spawned Agents
+
+When a skill that uses SilentDiscovery spawns a subagent (e.g. `create-plan` spawns `jdi-planner`), pass `DISCOVERED_STATE` into the spawn prompt as a named block:
+
+```
+Context already discovered: {DISCOVERED_STATE serialised as yaml}
+Do NOT re-read these scaffolding files. Surface open questions ONLY for facts you cannot infer from this block.
+```
+
+This avoids the common failure where the orchestrator reads scaffolding, spawns an agent, and the agent reads the same scaffolding again.
+
+---
+
+## Usage
+
+```
+<JDI:SilentDiscovery />
+```
+
+Referenced at the top of a skill's numbered workflow, typically as step 1 or 2. Always runs before any user-facing prompt.

package/framework/components/meta/StrictnessProtocol.md

@@ -0,0 +1,60 @@
+# StrictnessProtocol Component
+
+The discipline every JDI skill follows. Referenced by user-invocable commands to enforce deterministic, auditable behaviour on every invocation.
+
+When a command references `<JDI:StrictnessProtocol />`, these rules apply to the command's orchestration. They are **not suggestions** — they are the contract Claude honours for that skill.
+
+---
+
+## The Five Rules
+
+1. **Ask before assuming.** Never infer user intent from silence. If the skill requires information not visible on disk or in frontmatter, stop and ask. A missing answer is not permission to guess.
+
+2. **Present options, not mandates.** When multiple paths are valid, surface them as labelled choices (A / B / C) with the trade-off for each. The user picks — you do not pick for them and narrate.
+
+3. **The user decides strategy; you execute tactics.** Architecture, scope, priority, and verdict calls belong to the user. Naming, file placement, and code conventions belong to you. When in doubt which category a decision falls into, ask.
+
+4. **Never auto-run the next skill.** A skill's job ends when the user has a clear next action. Do not invoke downstream commands, spawn implementers after a plan approval, or chain skills silently. Each skill boundary is a human gate.
+
+5. **Adapt when the template doesn't fit.** The numbered workflow in each skill is the default path, not a prison. If the user's situation doesn't match any option, listen and adjust — but do so explicitly ("this doesn't fit option A/B/C/D — let me adapt…"), not by quietly drifting off-script.
+
+---
+
+## Inline Blocker Sentences
+
+Skills that reference this component will include explicit waiting sentences between steps, such as:
+
+- "Wait for the user's answer. Do not proceed until they respond."
+- "Store findings internally. Do NOT print them to the user yet."
+- "Stop here. Do not advance state until the user says `approved`."
+
+These are hard gates. Treat them as you would a `return` statement in code: execution stops until the condition is met.
+
+---
+
+## Silent Discovery Discipline
+
+Skills that also reference `<JDI:SilentDiscovery />` gather context from disk before asking questions. The two components compose:
+
+- `SilentDiscovery` defines **what** to read and how to store it
+- `StrictnessProtocol` defines **how** that discovered state shapes the conversation (never re-ask what's already on disk; surface findings only when relevant to the current step)
+
+---
+
+## Deviation Handling
+
+If you need to deviate from a skill's numbered workflow — because the user's situation doesn't fit, because a required file is missing, or because an edge case isn't covered — announce the deviation explicitly:
+
+> "This situation doesn't match the standard flow: {reason}. I'm going to {adapted approach} instead. Is that okay?"
+
+Then wait for confirmation. Silent deviation is the failure mode this protocol exists to prevent.
+
+---
+
+## Usage
+
+```
+<JDI:StrictnessProtocol />
+```
+
+Referenced in the footer of user-invocable commands (`/jdi:build`, `/jdi:create-plan`, `/jdi:implement-plan`, etc.) as the final reassertion of the non-negotiables before the HARD STOP gate.

package/framework/components/meta/TeamRouter.md

@@ -52,7 +52,7 @@ Activate members based on file types in the task:
 |---------|-----------|----------------|
 | Backend | `.php` files | jdi-backend |
 | Frontend | `.tsx`/`.ts` files | jdi-frontend |
-| Full-stack | Both PHP + TS | jdi-backend, jdi-frontend, jdi-executor |
+| Full-stack | Both PHP + TS | jdi-backend, jdi-frontend, jdi-programmer |
 | Commit | Any | jdi-committer |
 | PR generation | Any | jdi-pr-generator |
 | Plan creation | — | jdi-planner, jdi-product-lead |

package/framework/components/planning/TaskBreakdown.md

@@ -31,10 +31,12 @@ params:
 ## Task Format
 
 ```markdown
-<task id="{N}" type="auto|checkpoint:*" tdd="true|false" wave="{W}">
+<task id="{N}" type="auto|checkpoint:*" tdd="true|false" wave="{W}" priority="must|should|nice">
 
 ## Task {N}: {Name}
 
+**Priority:** must | should | nice
+
 **Objective:** {What this task accomplishes}
 
 **Files:**
@@ -81,3 +83,13 @@ When breaking down from REQUIREMENTS.yaml: map REQ-IDs to tasks, track which tas
 - **shallow**: 4-6 high-level tasks per feature
 - **standard**: 6-10 balanced tasks (default)
 - **deep**: 10-20 fine-grained tasks for complex/unfamiliar work
+
+---
+
+## Priority Bands
+
+Every task MUST be tagged with one of three priority bands:
+
+- **Must Have** (critical path — plan fails if not delivered)
+- **Should Have** (planned but droppable under pressure)
+- **Nice to Have** (delivered only with surplus capacity)

package/framework/components/planning/WaveComputation.md

@@ -47,7 +47,7 @@ Assign waves based on dependency resolution. Plans in the same wave can execute
 ### Step 4: Output
 
 **Inline**: Update each plan's frontmatter `wave` field.
-**JSON**: Return wave structure for executor with wave number, plan IDs, and parallelism flag.
+**JSON**: Return wave structure for programmer with wave number, plan IDs, and parallelism flag.
 
 ## Cross-Phase Dependencies
 

package/framework/config/jdi-config.yaml

@@ -45,7 +45,7 @@ models:
     quality:
       planner: opus
       architect: opus
-      executor: opus
+      programmer: opus
       verifier: sonnet
       researcher: sonnet
       phase_researcher: sonnet
@@ -57,7 +57,7 @@ models:
     balanced:
       planner: opus
       architect: opus
-      executor: sonnet
+      programmer: sonnet
       verifier: sonnet
       researcher: sonnet
       phase_researcher: sonnet
@@ -69,7 +69,7 @@ models:
     budget:
       planner: sonnet
       architect: sonnet
-      executor: sonnet
+      programmer: sonnet
       verifier: haiku
       researcher: haiku
       phase_researcher: haiku
@@ -80,7 +80,7 @@ models:
   # Override specific agents (null = use profile default)
   overrides:
     planner: null
-    executor: null
+    programmer: null
     verifier: null
     researcher: null
 

package/framework/jedi.md

@@ -26,7 +26,7 @@ model: opus
 >
 > The Claude Code Task tool **ONLY accepts `subagent_type="general-purpose"`** as a valid value.
 >
-> **If you use any other value** (e.g., `"jdi-executor"`, `"jdi-planner"`, or any custom type),
+> **If you use any other value** (e.g., `"jdi-programmer"`, `"jdi-planner"`, or any custom type),
 > the agent will fail with this error:
 >
 > ```
@@ -39,7 +39,7 @@ Agent identity is passed via the **prompt parameter**, NOT the `subagent_type` p
 
 ```
 Task(
-  prompt="You are jdi-executor. Read .jdi/framework/agents/jdi-executor.md for instructions. Execute: {task}",
+  prompt="You are jdi-programmer. Read .jdi/framework/agents/jdi-programmer.md for instructions. Execute: {task}",
   subagent_type="general-purpose"   ← MUST be "general-purpose"
 )
 ```
@@ -49,7 +49,7 @@ Task(
 ```
 Task(
   prompt="Execute the plan...",
-  subagent_type="jdi-executor"      ← WRONG: Causes classifyHandoffIfNeeded error
+  subagent_type="jdi-programmer"    ← WRONG: Causes classifyHandoffIfNeeded error
 )
 ```
 
@@ -212,7 +212,7 @@ Three profiles control which model each agent uses. Set in `.jdi/config/jdi-conf
 
 | Profile | When to Use | Opus Agents | Token Impact |
 |---------|-------------|-------------|--------------|
-| **quality** | Critical/complex work | planner, architect, executor, debugger | Highest — full Opus power |
+| **quality** | Critical/complex work | planner, architect, programmer, debugger | Highest — full Opus power |
 | **balanced** | Typical development (default) | planner, architect | ~40% less than quality |
 | **budget** | Conserve quota | None | ~60% less than quality |
 

package/framework/teams/engineering.md

@@ -1,7 +1,7 @@
 ---
 name: engineering
 description: Performs all engineering and coding tasks across backend and frontend
-members: [jdi-backend, jdi-frontend, jdi-architect, jdi-executor]
+members: [jdi-backend, jdi-frontend, jdi-architect, jdi-programmer]
 ---
 
 # Engineering Team
@@ -17,11 +17,11 @@ All coding and engineering — implementing features, fixing bugs, refactoring,
 | Backend Engineer | `jdi-backend` | `.jdi/framework/agents/jdi-backend.md` |
 | Frontend Engineer | `jdi-frontend` | `.jdi/framework/agents/jdi-frontend.md` |
 | Systems Architect | `jdi-architect` | `.jdi/framework/agents/jdi-architect.md` |
-| Senior Fullstack Engineer | `jdi-executor` | `.jdi/framework/agents/jdi-executor.md` |
+| Senior Fullstack Engineer | `jdi-programmer` | `.jdi/framework/agents/jdi-programmer.md` |
 
 ## Coordination
 
-Architect confirms approach → engineers implement within their stack → executor manages commits and deviation handling. All follow established project patterns.
+Architect confirms approach → engineers implement within their stack → programmer manages commits and deviation handling. All follow established project patterns.
 
 ## Boundaries
 

package/framework/templates/PLAN.md

@@ -9,6 +9,8 @@ type: implementation
 autonomous: true
 wave: 1
 gap_closure: false
+sprint_goal: ""
+carryover: []
 
 # Split plan task files (omit for legacy monolithic plans)
 task_files:
@@ -49,6 +51,12 @@ primary_agent: general-purpose
 
 ---
 
+## Sprint Goal
+
+{One sentence describing what this plan achieves toward the active milestone.}
+
+---
+
 ## Context
 
 **Read before executing:**
@@ -61,6 +69,15 @@ primary_agent: general-purpose
 **Previous work:**
 - {What's already done that this builds on}
 
+### Carryover
+
+| Task | Source Plan | Reason | New Estimate |
+|------|-------------|--------|--------------|
+
+### Risks
+
+Risks should be pulled from the `risks` block in `.jdi/REQUIREMENTS.yaml`. List the relevant ones here for execution-time reference.
+
 </section>
 
 ---
@@ -92,6 +109,13 @@ After all tasks complete, verify:
 - [ ] Tests pass: `{test command}`
 - [ ] Types check: `{type check command}`
 
+## Definition of Done
+
+- [ ] All Must Have tasks complete
+- [ ] All tasks pass acceptance criteria
+- [ ] No S1/S2 bugs (per jdi-quality taxonomy)
+- [ ] REQUIREMENTS.yaml updated for deviations
+
 ## Success Criteria
 
 This plan is complete when:

package/framework/templates/SUMMARY.md

@@ -198,4 +198,4 @@ Phases that can now proceed:
 
 ---
 
-*Generated by jdi-executor at {timestamp}*
+*Generated by jdi-programmer at {timestamp}*

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@benzotti/jedi",
-  "version": "0.1.42",
+  "version": "0.1.45",
   "description": "JDI - Context-efficient AI development framework for Claude Code",
   "type": "module",
   "bin": {