greprag 5.60.4 → 5.60.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (100) hide show
  1. package/dist/codex-chip-hooks.d.ts +2 -7
  2. package/dist/codex-chip-hooks.js +29 -153
  3. package/dist/codex-chip-hooks.js.map +1 -1
  4. package/dist/codex-steering.d.ts +2 -1
  5. package/dist/codex-steering.js +8 -5
  6. package/dist/codex-steering.js.map +1 -1
  7. package/dist/commands/codex-chip/bootstrap.d.ts +12 -0
  8. package/dist/commands/codex-chip/bootstrap.js +114 -0
  9. package/dist/commands/codex-chip/bootstrap.js.map +1 -0
  10. package/dist/commands/codex-chip/breakthrough-command.js +0 -7
  11. package/dist/commands/codex-chip/breakthrough-command.js.map +1 -1
  12. package/dist/commands/codex-chip/cleanup-command.js +21 -11
  13. package/dist/commands/codex-chip/cleanup-command.js.map +1 -1
  14. package/dist/commands/codex-chip/command.js +27 -49
  15. package/dist/commands/codex-chip/command.js.map +1 -1
  16. package/dist/commands/codex-chip/git.d.ts +19 -4
  17. package/dist/commands/codex-chip/git.js +82 -14
  18. package/dist/commands/codex-chip/git.js.map +1 -1
  19. package/dist/commands/codex-chip/goals.d.ts +9 -9
  20. package/dist/commands/codex-chip/goals.js +33 -73
  21. package/dist/commands/codex-chip/goals.js.map +1 -1
  22. package/dist/commands/codex-chip/help.d.ts +1 -1
  23. package/dist/commands/codex-chip/help.js +14 -25
  24. package/dist/commands/codex-chip/help.js.map +1 -1
  25. package/dist/commands/codex-chip/lifecycle.d.ts +4 -1
  26. package/dist/commands/codex-chip/lifecycle.js +14 -3
  27. package/dist/commands/codex-chip/lifecycle.js.map +1 -1
  28. package/dist/commands/codex-chip/model.d.ts +5 -1
  29. package/dist/commands/codex-chip/model.js.map +1 -1
  30. package/dist/commands/codex-chip/naming.js +4 -10
  31. package/dist/commands/codex-chip/naming.js.map +1 -1
  32. package/dist/commands/codex-chip/native.js +11 -19
  33. package/dist/commands/codex-chip/native.js.map +1 -1
  34. package/dist/commands/codex-chip/prompt.d.ts +2 -1
  35. package/dist/commands/codex-chip/prompt.js +20 -57
  36. package/dist/commands/codex-chip/prompt.js.map +1 -1
  37. package/dist/commands/codex-chip/resume-command.js +1 -4
  38. package/dist/commands/codex-chip/resume-command.js.map +1 -1
  39. package/dist/commands/codex-chip/selection.js +14 -55
  40. package/dist/commands/codex-chip/selection.js.map +1 -1
  41. package/dist/commands/codex-chip/worker.js +114 -44
  42. package/dist/commands/codex-chip/worker.js.map +1 -1
  43. package/dist/commands/codex-delivery.d.ts +32 -7
  44. package/dist/commands/codex-delivery.js +76 -92
  45. package/dist/commands/codex-delivery.js.map +1 -1
  46. package/dist/commands/codex-startup.js +1 -1
  47. package/dist/commands/codex-startup.js.map +1 -1
  48. package/dist/commands/codex-watch-health.d.ts +11 -0
  49. package/dist/commands/codex-watch-health.js +54 -0
  50. package/dist/commands/codex-watch-health.js.map +1 -1
  51. package/dist/commands/codex.js +39 -33
  52. package/dist/commands/codex.js.map +1 -1
  53. package/dist/commands/friction-reminder.d.ts +9 -9
  54. package/dist/commands/friction-reminder.js +12 -17
  55. package/dist/commands/friction-reminder.js.map +1 -1
  56. package/dist/commands/inbox-primer-reminder.js +3 -3
  57. package/dist/commands/inbox-primer-reminder.js.map +1 -1
  58. package/dist/commands/init.js +7 -5
  59. package/dist/commands/init.js.map +1 -1
  60. package/dist/commands/load-primer-reminder.js +2 -2
  61. package/dist/commands/load-primer-reminder.js.map +1 -1
  62. package/dist/commands/load.js +28 -27
  63. package/dist/commands/load.js.map +1 -1
  64. package/dist/commands/mechanic-spawn.d.ts +10 -0
  65. package/dist/commands/mechanic-spawn.js +67 -0
  66. package/dist/commands/mechanic-spawn.js.map +1 -0
  67. package/dist/commands/mechanic.js +6 -0
  68. package/dist/commands/mechanic.js.map +1 -1
  69. package/dist/commands/opencode-chip-lifecycle.d.ts +2 -0
  70. package/dist/commands/opencode-chip-lifecycle.js +137 -0
  71. package/dist/commands/opencode-chip-lifecycle.js.map +1 -0
  72. package/dist/commands/opencode-chip-mission.js +19 -0
  73. package/dist/commands/opencode-chip-mission.js.map +1 -1
  74. package/dist/commands/opencode-chip-store.d.ts +19 -1
  75. package/dist/commands/opencode-chip-store.js.map +1 -1
  76. package/dist/commands/opencode-chip.js +30 -13
  77. package/dist/commands/opencode-chip.js.map +1 -1
  78. package/dist/commands/opencode-goals.d.ts +5 -0
  79. package/dist/commands/opencode-goals.js +83 -0
  80. package/dist/commands/opencode-goals.js.map +1 -0
  81. package/dist/hook.js +8 -3
  82. package/dist/hook.js.map +1 -1
  83. package/dist/index.js +5 -90
  84. package/dist/index.js.map +1 -1
  85. package/dist/opencode-plugin.bundle.js +9 -11
  86. package/package.json +1 -1
  87. package/skill/greprag/SKILL.md +2 -2
  88. package/skill/greprag/docs/codex-chip.md +20 -64
  89. package/skill/greprag/docs/setup.md +15 -21
  90. package/skill/mechanic/SKILL.md +24 -0
  91. package/skill/templates/chip-bootloader.md +15 -10
  92. package/skill/templates/chip-leader-opencode.md +64 -50
  93. package/skill/templates/chip-leader.md +81 -221
  94. package/skill/templates/codex-chip-spawn.md +150 -174
  95. package/skill/templates/codex-subagent-spawn.md +32 -0
  96. package/dist/commands/codex-native-delivery.d.ts +0 -70
  97. package/dist/commands/codex-native-delivery.js +0 -285
  98. package/dist/commands/codex-native-delivery.js.map +0 -1
  99. package/skill/templates/reflex-chip.md +0 -58
  100. package/skill/templates/workshop-chip.md +0 -46
@@ -1,178 +1,154 @@
1
- # Codex Chip Spawn
2
-
3
- This is the Codex Desktop chip method. It is separate from Claude Code
4
- `spawn_task`: never use or copy the Claude Block 1/Block 2 prompt here.
5
-
6
- Exact visible titles are role contracts: `PLANNER: <Mission>` owns intent and
7
- acceptance, `LEAD: <Mission>` is always Luna/xhigh and owns orchestration,
8
- `Chip A/B/C: <Specific Purview>` are Luna/xhigh workers, and
9
- `ADVISOR: <Purview>` is Sol/high advice for a documented fundamental blocker.
10
-
11
- ## Gate: one chip or a mission?
12
-
13
- A single independent task proceeds directly. If two or more chips target one
14
- objective, or you are about to create a second chip, stop and run `greprag load
15
- chip-leader`. Plan the integration branch, ownership seams, dependency order,
16
- merge order, and whole-feature test gate before another spawn. Rename the
17
- orchestrating task so its title begins `LEAD: <Mission>`. Multi-chip workers are
18
- uniquely named `Chip A: <Specific Purview>`, `Chip B: ...`; a single worker is
19
- `Chip: <Purview>`. Labels are stable coordination handles, not execution order.
20
-
21
- ## Prepare the isolated task
22
-
23
- Every mission starts with a durable parent-owned goal. Give it a concrete
24
- objective, final state, and stable acceptance criterion IDs. Declare
25
- non-overlapping ownership leases for paths a chip may change; research may omit
26
- a lease when it only reports evidence. All roles share the same execution
27
- contract—the mission and goal define the work.
28
- After the planner attaches the Luna LEAD, the LEAD creates one nested goal and
29
- runs `greprag codex chip goal bind-lead <lead-id> --goal-id <nested-goal-id>`.
30
- That emits `GOAL_READY:<goalId>`; no LEAD execution or child dispatch is valid
31
- before it. All later Chips, ADVISOR, and MECHANIC tasks use that exact goal.
32
-
33
- ```bash
34
- greprag codex chip goal create \
35
- --objective "<concrete objective>" \
36
- --final-state "<observable final state>" \
37
- --criterion <id>:"<acceptance statement>"
38
-
39
- greprag codex chip spawn "<independent task>" \
40
- --name <slug> \
41
- --title "<Properly Capitalized Purview>" \
42
- --goal-id <goal-id> --covers <criterion-id> \
43
- --owns "<path/**>" \
44
- --codex-project-id <desktop-project-id> \
45
- --parent-session <parent-thread-id> \
46
- --json
1
+ # Codex Orchestration
2
+
3
+ Choose the smallest primitive that matches the work. This method is about
4
+ discoverable task shape; titles are coordination labels, not execution
5
+ authority.
6
+
7
+ ## Identity first
8
+
9
+ For any coordinated multi-chip mission, rename the orchestrating task before
10
+ spawning children:
11
+
12
+ ```text
13
+ LEAD: <Mission>
14
+ ```
15
+
16
+ Then name children with the exact ordinal schema:
17
+
18
+ ```text
19
+ Chip A: <Specific Purview>
20
+ Chip B: <Specific Purview>
21
+ Chip C: <Specific Purview>
22
+ ```
23
+
24
+ In quick mode, the current task renames itself `LEAD: <Mission>` and directly
25
+ spawns 1–2 children. It is the **implicit LEAD**; no separate leader task is
26
+ created. In Leader mode, the initiator creates a separate `LEAD: <Mission>`
27
+ task, and that LEAD spawns and manages the children.
28
+
29
+ ## Three primitives
30
+
31
+ ### 1. Internal subagent
32
+
33
+ Use this for ephemeral analysis, research, or bounded edits/tests that can stay
34
+ inside the current session. Load `greprag load codex-subagent-spawn` first.
35
+
36
+ - Same-session and short-lived; results return to the parent context.
37
+ - No worktree, durable task manifest, inbox identity, or goal is created.
38
+ - Keep the session bounded at `max_threads=6` and `max_depth=1`.
39
+ - `fast_scan` is read-only; `routine_worker` and `deep_worker` may make bounded
40
+ edits/tests in the parent workspace. The parent avoids overlapping writes and
41
+ owns integration.
42
+ - If the work needs a visible child, independent persistence, or its own
43
+ worktree, use a quick chip instead.
44
+
45
+ ### 2. Quick chip
46
+
47
+ Use this for 1–2 visible, durable worktree tasks with one initiating parent.
48
+ The initiating task is the implicit LEAD after it renames itself; it may
49
+ dispatch `Chip A` and `Chip B` directly.
50
+
51
+ - Each child gets its own visible task and worktree.
52
+ - Children are writable ordinary chips. Do not add a read-only role, lease,
53
+ mandatory nested goal, or delivery-proof gate.
54
+ - Preserve the visible native task identity, isolated worktree, concise final
55
+ report, parent review/integration, and parent-owned archive + cleanup. Normal
56
+ completion is the native parent-child task result; `greprag send` remains
57
+ available for explicit cross-harness or peer messaging, but is not mandatory
58
+ chip ceremony. One report uses one rail: never repeat a native DONE/BLOCKED
59
+ result with the same payload over GrepRAG inbox. CLI-runtime chips still use
60
+ the inbox terminal event because they have no native parent-child result.
61
+
62
+ ### 3. Explicit Leader mission
63
+
64
+ Use this when the work is more than the quick 1–2-chip shape, or when shared
65
+ files, contracts, ordering, integration, or a seam require a dedicated
66
+ orchestrator. The initiator creates the separate `LEAD: <Mission>` task first.
67
+ That LEAD decomposes the mission, assigns exact `Chip A/B/C: <Specific Purview>`
68
+ titles, dispatches ordinary writable chips, reconciles their reports, and owns
69
+ integration checks and cleanup.
70
+
71
+ Load `greprag load chip-leader` for the mission worksheet before dispatch.
72
+
73
+ ## Codex Desktop dispatch route
74
+
75
+ Create the child directly with `codex_app__create_thread` using the current
76
+ project with this target schema:
77
+
78
+ ```json
79
+ {
80
+ "type": "project",
81
+ "projectId": "<current-project-id>",
82
+ "environment": { "type": "worktree" }
83
+ }
84
+ ```
85
+
86
+ Pass the required child opening prompt below as the initial prompt. Omit
87
+ `startingState` unless the mission explicitly requires a particular existing
88
+ branch/ref or the caller's working-tree state; never use it to name a new
89
+ branch. After creation, set the exact visible title when needed.
90
+
91
+ ## Shared chip contract
92
+
93
+ Visible chips keep the useful durable boundaries:
94
+
95
+ 1. Start in an isolated worktree with a clear purview and parent task
96
+ relationship.
97
+ 2. Make the change or investigation within that worktree; commit when there is
98
+ a durable result.
99
+ 3. Return a final `DONE` or `BLOCKED` result to the parent with commit, checks,
100
+ and caveats. Use `greprag send` only when explicit messaging is useful.
101
+ 4. The parent reviews and integrates reported work, then archives the Codex
102
+ task; Codex owns its managed-worktree lifecycle.
103
+
104
+ The child never silently changes the orchestration shape. If the work grows
105
+ from quick to Leader-scale, tell the parent and let the parent create the
106
+ dedicated `LEAD: <Mission>` task.
107
+
108
+ ## Selection rule
109
+
110
+ ```text
111
+ bounded thought, no durable surface → internal subagent
112
+ 1–2 visible worktree tasks → quick chip; current task is LEAD
113
+ more chips or shared seams → separate LEAD mission
47
114
  ```
48
115
 
49
- The parent/`LEAD:` selects each worker model before dispatch; the child never
50
- self-selects or changes it. `LEAD` and ordinary Chips are fixed to
51
- `gpt-5.6-luna/xhigh`.
52
- `PLANNER` may use Luna/xhigh or explicitly Sol/high. `ADVISOR` must be
53
- Sol/high, and carry `--model-reason "Fundamental blocker: ..."`.
54
- The old `--complex`, `--profile complex`, and `--complexity-signal` routing is
55
- rejected for new spawns. Native Desktop `thinking` uses the callable enum and
56
- is checked against the selected model's advertised effort matrix. The manifest
57
- persists role, model, effort, parent session, reason, and criterion evidence.
58
- The auditable selection fields are `selectedBy`, `reason`, and `matched signals`.
59
- The hard-signal rubric covers `architecture/API/schema` and
60
- `high-risk migration/security/accounting`; a scope boundary sends a
61
- `breakthrough message` and the child `never swaps models autonomously`.
62
-
63
- Native Desktop is the default runtime.
64
- `--runtime cli` is opt-in and only valid when PATH Codex `model/list` actually
65
- exposes the requested model and effort; validation remains fail-loud.
66
-
67
- For a multi-chip mission every spawn also uses `--multi-chip --label A` (then B,
68
- C...) and a different `--title`. Duplicate active slugs, labels, or purview
69
- titles fail loudly.
70
-
71
- The spawn command creates a unique starting branch, records the manifest and
72
- lease, and returns a `greprag-codex-native-v4` handoff. Pass `createRequest`
73
- exactly to native `create_thread`: it already contains the full real mission,
74
- selected `model`, `thinking`, project target, and worktree starting branch.
75
- The native target schema is `target.type=project` with
76
- `startingState={type:"branch", branchName}` inside the worktree environment;
77
- do not invent a checkout path or second bootstrap turn. Do not add `cwd`, `title`, `model`, or `effort` to the native create request; those values belong to the handoff and post-create verification contract.
78
- `expectedBaseSha` is the attach-time commit invariant behind that reserved branch.
79
- This is the only assignment turn. Never create a bootstrap task and never send
80
- the mission again after attach.
81
-
82
- Creation returns `clientThreadId` while Codex builds its own detached worktree.
83
- The initial `UserPromptSubmit` hook provisionally binds the manifest and native
84
- cwd before tool use. Resolve `threadId` + actual cwd immediately, then call
85
- `set_thread_title` with the exact handoff title and read it back twice. Retry at
86
- most three times if auto-title overwrites it; fail loudly if it will not remain
87
- exact. `create_thread` has no title field, so the mission's first line carries
88
- the correct identity immediately and task metadata is renamed as soon as the
89
- resolved task exists. Only then run
90
- `verifyTitleCommand`, rerun handoff, and run `attachCommand`. Attach validates
91
- project/base/sandbox attestation, writes the marker, sends parent `IN-FLIGHT`,
92
- and starts the monitor. The enforced order is create-real-mission → provisional
93
- bind → resolve → rename/verify → attach → IN-FLIGHT → monitor. A standalone CLI cannot
94
- invoke the Desktop-owned surface, so it prepares rather than pretending an old
95
- PATH app-server successfully ran a 5.6 turn.
96
- The title race contract is `set_thread_title` → read it back twice →
97
- `IN-FLIGHT → mission` monitor only after the exact title remains stable.
98
-
99
- ## Mandatory parent inbox lifecycle
100
-
101
- The child must address the recorded parent session, not a bare mailbox:
102
-
103
- - `IN-FLIGHT` immediately after it starts work.
104
- - `DONE` before ending, with commit + checks, by running the exact `codex chip
105
- report` command in its opening prompt.
106
- - `BLOCKED` before ending when it cannot finish, by running the exact `codex
107
- chip block` command.
108
- - If the work crosses the selected model boundary, run
109
- `codex chip breakthrough <id> --reason "..."`. This emits a typed
110
- `BREAKTHROUGH` event to the recorded parent; the child never swaps models.
111
-
112
- The attached host monitor validates receipts from the recorded native cwd,
113
- exact base ancestry, clean state, and every changed path against the lease. A
114
- detached HEAD is valid; the host imports the reported exact commit into the
115
- reserved chip ref, then sends the terminal inbox event. The
116
- child never merges, pushes, cleans up, or edits the parent checkout. Reports map
117
- concrete evidence to every covered goal criterion. The parent reviews the diff,
118
- integrates it, and runs `greprag codex chip goal accept <goal-id> --summary
119
- "<review judgment>"` only when all criteria and chips are satisfied. A
120
- LEAD-owned goal with no additional child chip records final proofs with
121
- `goal attest --commit <release-commit>` plus repeated `--evidence` and `--check`
122
- before acceptance. For a verified squash/cherry-pick add `--integrated <chip-id>`
123
- to acceptance. Acceptance
124
- returns machine-readable closeout entries: apply each native `archiveRequest`
125
- first, then its exact `cleanupCommand`. Cleanup does not imply acceptance, is
126
- refused before it, and requires `--native-archived` for native tasks.
127
-
128
- Native chips require parent-side `--native-model-verified` proof before monitor
129
- start and have a receipt deadline (default 180 minutes; override with
130
- `--native-timeout-minutes`). This standalone CLI cannot query Desktop-private
131
- turn status, so it never guesses that a settled task succeeded: write *and read*
132
- chips must submit `report`/`block`, and timeout fails loudly. One live monitor
133
- per chip is enforced. `reconcile` expires unattached setup after 10 minutes,
134
- retires stale blocked chips after 24 hours, and surfaces terminal-delivery
135
- failure. Lifecycle inbox sends validate HTTP status, target session, sender
136
- session, and durable event receipts; a duplicate monitor cannot double-send.
137
- If initial `IN-FLIGHT` delivery fails, attach remains verified and retryable
138
- instead of terminally stranding the task. Server-side idempotency serializes
139
- the claim and preserves the originally resolved target across retries.
140
-
141
- The native worktree sandbox is the physical boundary. Verification accepts only
142
- the Codex-issued `client-new-thread:<uuid>` token (or its bare UUID form), a
143
- distinct resolved UUID task ID, the expected project/base proof,
144
- an attested `workspace-write` sandbox, and a Git root beneath Codex's own
145
- `worktrees` directory at the exact base commit. Hook guards require the exact
146
- bound task/cwd/sandbox and deny out-of-lease file tools, destructive
147
- Git/cleanup, and symlink/junction creation; link-based escape is never allowed.
148
- Generated verify/attach/report commands pin resolved stable Node and CLI paths,
149
- so restarting Codex does not invalidate an in-flight chip contract.
150
-
151
- Useful recovery commands:
152
-
153
- ```bash
154
- greprag codex chip handoff <id> --json
155
- greprag codex chip status <id>
156
- greprag codex chip breakthrough <id> --reason "<follow-up>"
157
- greprag codex chip resume <id>
158
- greprag codex chip stop <id>
116
+ Do not use a larger coordination layer merely because the task sounds
117
+ important. Use the smallest shape that preserves the required visibility,
118
+ worktree isolation, reporting, messaging, and cleanup.
119
+
120
+ ## Required child opening prompt
121
+
122
+ Generate the child assignment with this short handoff. Keep the real outcome
123
+ dominant and do not require a parent-authored implementation plan:
124
+
125
+ ```text
126
+ Chip <Label>: <Specific Purview>
127
+
128
+ ## Setup — do this FIRST
129
+ Stay in the Codex-provided isolated worktree; do not create a second worktree.
130
+ Read AGENTS.md and the session-start recap, then inspect the current repo state.
131
+ No leases, read-only mode, or goals.
132
+ If the exact first-line title is `MECHANIC: <Mission>`, make `greprag load
133
+ mechanic` the first Setup action before diagnosis or edits.
134
+
135
+ ## Task
136
+ Outcome: <desired observable result>
137
+ Why: <one sentence; omit if obvious>
138
+ Seams: <shared files/contracts/order, or none>
139
+ Starting state / integration: <what this worktree starts from and who integrates>
140
+ Acceptance: <checks/evidence that mean done>
141
+ Own repository discovery, design, implementation, tests, and commit; do not
142
+ wait for a parent-authored implementation plan.
143
+
144
+ ## Report when done
145
+ Return DONE or BLOCKED to the parent with the commit hash, concise result,
146
+ checks, and caveats. Do not merge, push, deploy, or delete the worktree; the
147
+ parent reviews and cleans up. Normal completion is the native parent-child task
148
+ result, not a nonce/ACK protocol or mandatory GrepRAG inbox ceremony.
159
149
  ```
160
150
 
161
- For a native chip, `BREAKTHROUGH` is the sole agent-visible control envelope;
162
- native turn transport remains private. Breakthrough delivery is
163
- durably queued → injected → acknowledged → acted; empty completed turns are
164
- not delivery, and natural-turn drain is degraded fallback only. Stop fails
165
- loud until the parent interrupts the Desktop task, then confirms that fact with
166
- `stop <id> --native-interrupted`; the CLI never records a false cancellation.
167
- After restart/usage interruption, use `resume`, deliver its handoff, and wait for
168
- the nonce-bound breakthrough acknowledgment. A delivered message without that
169
- ack is not recovery. Cleaned/cancelled/failed tasks cannot resume; relaunch them.
170
- For an invalid terminal launch, preserve the mission and run `goal exclude
171
- <goal-id> --chip <old-chip-id> --reason "<concrete reason>"` before spawning its
172
- replacement. Excluded evidence cannot satisfy acceptance. To abandon the whole
173
- mission, stop every chip first, then use `goal cancel <goal-id> --reason
174
- "<concrete reason>"`; cancelled closeout is not acceptance.
175
-
176
- Mechanic repair incidents are not Mechanic task termination: `REPAIR-READY/CLOSED`
177
- returns the same Luna/xhigh Mechanic to `OPEN+DORMANT` for later typed friction.
178
- Only final LEAD teardown may accept/clean it with `--mechanic-final`.
151
+ The first line is the exact visible title, alone. Substitute the appropriate
152
+ discoverability label: `Chip A: <Specific Purview>`, `LEAD: <Mission>`,
153
+ `ADVISOR: <Purview>`, or `MECHANIC: <Mission>`. These labels do not change
154
+ execution authority.
@@ -0,0 +1,32 @@
1
+ # Codex Internal Subagent
2
+
3
+ Use an internal subagent for ephemeral, same-session work: a bounded research
4
+ pass, comparison, review, edit, or test whose result can return directly to the
5
+ current task.
6
+
7
+ ## Contract
8
+
9
+ - Load this method with `greprag load codex-subagent-spawn` when the shape is
10
+ not already in context.
11
+ - The subagent is ephemeral and same-session. It has no visible worktree task,
12
+ durable manifest, inbox identity, or goal.
13
+ - Keep concurrency at `max_threads=6` and recursion at `max_depth=1`.
14
+ - Give it one specific question or purview and ask for a compact result with
15
+ evidence. `fast_scan` is read-only; `routine_worker` and `deep_worker` may
16
+ perform bounded edits/tests in the parent workspace.
17
+ - The parent prevents overlapping concurrent edits and owns the final judgment,
18
+ integration, and any commit that should outlive the session.
19
+ - Do not use it for independent worktree isolation, parent-visible lifecycle
20
+ reporting, or work that must outlive the session; choose a quick chip instead.
21
+
22
+ ## Compact brief
23
+
24
+ ```text
25
+ Subagent purview: <one bounded question>
26
+ Context: <the files or facts it may inspect>
27
+ Return: <decision / findings / recommended next step>
28
+ ```
29
+
30
+ Internal subagents do not need `greprag send`; their result is returned to the
31
+ initiating task. If you need a visible child identity, report, or cleanup
32
+ boundary, stop using this primitive and load `codex-chip-spawn`.
@@ -1,70 +0,0 @@
1
- export type NativeDeliveryState = 'queued' | 'native-delivered' | 'acknowledged' | 'acted' | 'degraded';
2
- export interface NativeCodexSendRequest {
3
- threadId: string;
4
- prompt: string;
5
- messageId: string;
6
- nonce: string;
7
- ackMarker: string;
8
- }
9
- export interface NativeCodexSender {
10
- /** The Codex host adapter must implement the native app-layer primitive. */
11
- send_message_to_thread(request: NativeCodexSendRequest): Promise<unknown>;
12
- }
13
- export interface NativeDeliveryEnvelope {
14
- version: 1;
15
- messageId: string;
16
- nonce: string;
17
- targetSession: string;
18
- summary: string;
19
- state: NativeDeliveryState;
20
- attempts: number;
21
- requestedAt: string;
22
- nativeDeliveredAt?: string;
23
- acknowledgedAt?: string;
24
- actedAt?: string;
25
- lastError?: string;
26
- action?: string;
27
- }
28
- export interface NativeDeliveryResult {
29
- ok: boolean;
30
- method: 'send_message_to_thread';
31
- reason?: string;
32
- lifecycle: NativeDeliveryState;
33
- nonce: string;
34
- threadId: string;
35
- ackMarker: string;
36
- visible: boolean;
37
- acknowledged: boolean;
38
- acted: boolean;
39
- action?: string;
40
- attempts: Array<{
41
- method: string;
42
- ok: boolean;
43
- detail?: string;
44
- }>;
45
- }
46
- export declare function deliveryNonce(messageId: string): string;
47
- export declare function deliveryAckMarker(messageId: string): string;
48
- export declare function readNativeEnvelope(messageId: string): NativeDeliveryEnvelope | null;
49
- export declare function queueNativeEnvelope(messageId: string, targetSession: string, summary: string, nonce?: string): NativeDeliveryEnvelope;
50
- export declare function markNativeDelivered(messageId: string): NativeDeliveryEnvelope;
51
- /** ACK mutates the original nonce only. It never sends a reply message. */
52
- export declare function acknowledgeNativeDelivery(messageId: string, nonce: string, action: string): NativeDeliveryEnvelope;
53
- export declare function markNativeActed(messageId: string, nonce: string, action: string): NativeDeliveryEnvelope;
54
- export declare function markNativeDegraded(messageId: string, error: string): NativeDeliveryEnvelope;
55
- /**
56
- * Load the host bridge supplied by Codex Desktop. A plain CLI process cannot
57
- * call an MCP/app tool by pretending that app-server is native, so the bridge
58
- * is explicit and fail-closed. The module must export the exact primitive name
59
- * `send_message_to_thread`; its result must contain bound visible ACK/action
60
- * proof before GrepRAG reports success.
61
- */
62
- export declare function loadNativeCodexSender(env?: NodeJS.ProcessEnv): NativeCodexSender | null;
63
- export declare function nativeAdapterConfigured(env?: NodeJS.ProcessEnv): boolean;
64
- export declare function deliverViaNativeCodex(opts: {
65
- messageId: string;
66
- targetSession: string;
67
- prompt: string;
68
- nonce?: string;
69
- nativeSender?: NativeCodexSender;
70
- }): Promise<NativeDeliveryResult>;