greprag 5.74.5 → 5.74.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "greprag",
-  "version": "5.74.5",
+  "version": "5.74.6",
   "description": "GrepRAG — agent memory for Claude Code, Codex, and OpenCode.",
   "main": "dist/index.js",
   "bin": {

package/skill/templates/chip-leader.md

@@ -41,6 +41,15 @@ verifies the active goal names this mission before fanout. That native goal
 tracks the LEAD mission; it is not a GrepRAG lease, durable manifest, or child
 permission gate.
 
+LEAD is an orchestrator, not an implementation chip. After `create_goal` /
+`get_goal`, the LEAD's next required action is creating the listed
+`Chip A/B/C: <Specific Purview>` visible Codex tasks/worktrees. Before all
+required children exist, LEAD must not implement the phase, edit application,
+worker, or product source files, or treat Chip A/B/C as sections of its own work. If
+child creation fails, LEAD stops and reports `BLOCKED`; it must not continue
+solo. Allowed LEAD edits are mission/runtime docs, integration reconciliation
+after chip reports, and tiny mechanical conflict fixes during merge.
+
 ## Quick versus Leader
 
 - **Quick:** the current task renames itself `LEAD: <Mission>` and directly
@@ -87,7 +96,8 @@ ordering in the brief rather than relying on hidden coordination metadata.
    blocker, explicit LEAD decision request, or operator status request.
 4. In the dedicated LEAD, create the native top-level mission goal with
    `create_goal`, then verify it with `get_goal`.
-5. From the LEAD, spawn each `Chip A/B/C: <Specific Purview>` with its own
+5. Next, before any implementation edit, spawn each
+   `Chip A/B/C: <Specific Purview>` with its own
    visible worktree and the mission context it needs.
    A `FIX: [type] <one friction unit>` child must make `greprag load mechanic` its
    first Setup action before diagnosis or edits.

package/skill/templates/codex-chip-spawn.md

@@ -116,7 +116,14 @@ exists, run `node scripts/ensure-npm-deps.cjs`; if
 another checkout.
 If the exact first-line title is `LEAD: <Mission>`, create a native top-level
 mission goal with `create_goal`, then run `get_goal` and verify the active goal
-names this mission before any child fanout.
+names this mission before any child fanout. Then create the listed
+`Chip A/B/C: <Specific Purview>` visible Codex tasks/worktrees before any
+implementation edit. LEAD is an orchestrator, not an implementation chip: do
+not implement the phase, edit app/worker/product source files, or treat
+Chip A/B/C as sections of your own work before all required children exist. If
+child creation fails, stop and report `BLOCKED`; do not continue solo. Allowed
+LEAD edits are mission/runtime docs, integration reconciliation after chip
+reports, and tiny mechanical conflict fixes during merge.
 If the exact first-line title starts with `FIX:`, run
 `greprag load mechanic` before diagnosis or edits.
 If the exact first-line title is `ADVISOR: <Purview>`, report consultation to