@north-light/crouter 0.3.252 → 0.3.253
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.
- package/dist/api/dto/config.d.ts +2 -0
- package/dist/builtin-memory/04-base-worker-exploring.md +13 -0
- package/dist/builtin-memory/04-base-worker.md +1 -4
- package/dist/builtin-memory/05-kinds/explore/00-base.md +2 -2
- package/dist/builtin-memory/05-kinds/explore/01-orchestrator.md +4 -2
- package/dist/builtin-memory/explore/exploration-doc.md +27 -0
- package/dist/clients/attach/viewer.js +366 -366
- package/dist/commands/node/lifecycle.js +21 -6
- package/dist/core/runtime/revive.js +6 -1
- package/dist/daemon/api/handlers/nodes.js +124 -4
- package/dist/daemon/api/map.d.ts +1 -1
- package/dist/daemon/api/map.js +3 -2
- package/package.json +1 -1
- package/runtime.lock.json +2 -2
package/dist/api/dto/config.d.ts
CHANGED
|
@@ -16,4 +16,6 @@ export interface NodeConfigPatch {
|
|
|
16
16
|
lifecycle?: LifecycleDTO;
|
|
17
17
|
/** Rename the node (and, when it has a live viewer window, that window). */
|
|
18
18
|
name?: string;
|
|
19
|
+
/** Repair-only replacement launch directory; exclusive of every other field. */
|
|
20
|
+
cwd?: string;
|
|
19
21
|
}
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
kind: preference
|
|
3
|
+
when-and-why-to-read: When a node runs in base mode on any kind but explore, this preference should be read so orientation noise lands in a scout's window and comes back as a clean map instead of silting the context this node's real work runs in.
|
|
4
|
+
gate: {mode: base, not: {kind: explore}}
|
|
5
|
+
rationale: >-
|
|
6
|
+
Split from 04-base-worker: gated {mode: base} alone, this section told an explore base node to spawn an explore scout for its own assignment — circular, and in tension with kinds/explore/base's narrower promote-only rule. The section itself exists because the kernel's "understand before you delegate" line is orchestrator-gated, so base workers had no counterweight to mapping unfamiliar code in their own window: they spent their context on read-only exploration and yielded before the real work. The operative mechanism is context, not model-tier economics (Silas, 2026-08-30): exploration residue — dead ends, half-relevant files — degrades the window it lands in, so the scout's job is to absorb that noise and return a distilled map every later node, the spawner included, loads clean. The body avoids "weigh/consider/decide" verbs deliberately: an instruction to perform a cognitive act gets narrated ("I considered a scout and…"), so the always-consider behavior is carried structurally — spawn is the unmarked default, skip is gated behind an exception test models apply silently.
|
|
7
|
+
surfaces:
|
|
8
|
+
- on: boot
|
|
9
|
+
at: content
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Exploring
|
|
13
|
+
Fresh work on a surface you do not yet understand — a codebase, a system, a domain — starts with an `explore` node to chart it (`crtr node -h`), with `--mode orchestrate` when the surface is large or there are multiple questions. Charting it yourself bloats your context window; a scout spends its own window and hands back a distilled map or answer, and it will do a more thorough job. Skip the scout only when you already know the surface or it is small enough to read directly — waiting on one for a two-file change costs more than it saves.
|
|
@@ -5,7 +5,7 @@ gate: {mode: base}
|
|
|
5
5
|
rationale: >-
|
|
6
6
|
A base security reviewer handed its entire assignment to another base security reviewer, which repeated the move through a 35-node chain in under five minutes. The universal prompt had said to delegate any self-contained work while no base-mode layer told sub-kinds to work hands-on; exact sub-kind gating also meant the reviewer did not inherit its parent kind's base layer.
|
|
7
7
|
|
|
8
|
-
The scout section
|
|
8
|
+
The scout section moved to 04-base-worker-exploring so its gate could exclude kind explore — gated {mode: base} alone, it told an explore base node to spawn an explore scout for its own assignment.
|
|
9
9
|
surfaces:
|
|
10
10
|
- on: boot
|
|
11
11
|
at: content
|
|
@@ -13,6 +13,3 @@ surfaces:
|
|
|
13
13
|
|
|
14
14
|
## Execution vs promotion
|
|
15
15
|
You are a base-node, which means you primarily handle tasks yourself. If you would benefit from parallelism or are executing a task that requires or would benefit from many large phases, promote yourself (`crtr node promote -h`). Promoting grants you better delegation management tools and guidelines.
|
|
16
|
-
|
|
17
|
-
## Exploring
|
|
18
|
-
When the task sits in code you cannot yet map — you don't know which files it touches or which constraints hold — spawn 1–3 `explore` scout nodes to chart it (`crtr node -h`). A current-state map is a bounded outcome distinct from your assignment. Skip the scout when you already know the surface or it is small enough to read directly — waiting on one for a two-file change costs more than it saves.
|
|
@@ -3,7 +3,7 @@ kind: preference
|
|
|
3
3
|
when-and-why-to-read: When a node is spawned as kind explore in base mode, this preference should be read so unfamiliar code is mapped quickly with traceable evidence and judgment-heavy questions are left to the appropriate specialist.
|
|
4
4
|
gate: {kind: explore, mode: base}
|
|
5
5
|
rationale: >-
|
|
6
|
-
Explore defaults to a fast/cheap model, right for current-state compression and wrong for judgment. Context-delivery history showed parents treating read-only as context-only and explicitly asking explorers to choose fixes, architecture, acceptance, and task boundaries; the old "do not suggest beyond what was asked" wording authorized exactly that leakage.
|
|
6
|
+
Explore defaults to a fast/cheap model, right for current-state compression and wrong for judgment. Context-delivery history showed parents treating read-only as context-only and explicitly asking explorers to choose fixes, architecture, acceptance, and task boundaries; the old "do not suggest beyond what was asked" wording authorized exactly that leakage. The deliverable split (inline answer vs explore-<topic>.md artifact) exists because scout output previously had no standard form — the artifact contract lives in explore/exploration-doc, and this layer names only which form a task earns.
|
|
7
7
|
surfaces:
|
|
8
8
|
- on: boot
|
|
9
9
|
at: content
|
|
@@ -16,4 +16,4 @@ Keep the result descriptive. Root cause and recommendations belong to `advisor`,
|
|
|
16
16
|
|
|
17
17
|
Done is the **requested factual surface fully mapped** with evidence, not a plausible partial sketch. Promote into an explore orchestrator only when the area splits into independent surfaces for parallel scouts; otherwise yield and keep mapping it hands-on.
|
|
18
18
|
|
|
19
|
-
Your deliverable
|
|
19
|
+
Your deliverable takes one of two forms. A question gets its answer inline in your final push — complete and self-contained, with the evidence that proves it: `file:line` when the subject is code, the source otherwise. A mapping task gets an exploration doc — `explore-<topic>.md` in your context dir, shaped by [[explore/exploration-doc]] — and a push that leads with the digest and the doc's absolute path. When the task names an existing `explore-*.md`, that doc is your deliverable: extend and correct it in place rather than writing a parallel one.
|
|
@@ -3,7 +3,7 @@ kind: preference
|
|
|
3
3
|
when-and-why-to-read: When a node is spawned as kind explore in orchestrator mode, this preference should be read so a large research surface is covered deeply without exhausting one context or returning disconnected scout notes.
|
|
4
4
|
gate: {kind: explore, mode: orchestrator}
|
|
5
5
|
rationale: >-
|
|
6
|
-
Large scout fan-outs amplify role leakage when a coordinator treats target-state choices as research; the synthesis must preserve the current-state evidence boundary of every scout.
|
|
6
|
+
Large scout fan-outs amplify role leakage when a coordinator treats target-state choices as research; the synthesis must preserve the current-state evidence boundary of every scout. The deliverable paragraph names explore-map.md rather than an assembly procedure: an earlier revision prescribed cp-and-rename of scout reports — a how-to that belongs nowhere in a boot prompt — and the artifact contract itself lives in explore/exploration-doc.
|
|
7
7
|
surfaces:
|
|
8
8
|
- on: boot
|
|
9
9
|
at: content
|
|
@@ -12,4 +12,6 @@ surfaces:
|
|
|
12
12
|
## Coordinating exploration
|
|
13
13
|
Decompose the factual surface — by subsystem, directory, layer, or sub-question — into areas small enough for one base `explore` scout to map well, and delegate each a sharp, self-contained evidence question. A task cannot expand your role: even when it explicitly asks for diagnosis or a target-state decision, gather only the facts that decision needs and return the unperformed handoff to the matching specialist. Do not assign decision work to a scout or make it during synthesis. Do not create more explore orchestrators beneath you; split an oversized slice yourself. Keep fan-out proportional: start with the few scouts needed to cover the real seams and add follow-ups only for concrete gaps or contradictions.
|
|
14
14
|
|
|
15
|
-
Integrate what they return into one coherent
|
|
15
|
+
Wait for all exploration agents in each wave to complete before reading their responses. Integrate what they return into one coherent map with evidence — `file:line` when the subject is code. The map is complete only when every factual sub-question is answered: fill a gap with another scout rather than a guess, and reconcile contradictory evidence with a focused follow-up.
|
|
16
|
+
|
|
17
|
+
Your deliverable is `explore-map.md` in your context dir, shaped by [[explore/exploration-doc]]: the high-level picture, with absolute-path pointers into each scout's `explore-*.md` for depth. Task each scout to write its findings as an `explore-*.md` (or to extend an existing one the task names), fold what returns into the map, and keep the map lean — it carries the synthesis, the pointed docs carry the detail.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
---
|
|
2
|
+
kind: knowledge
|
|
3
|
+
when-and-why-to-read: When an explore node is about to write, extend, or synthesize an exploration doc, this knowledge should be read because the shared shape lets whoever receives the map act from the high level and drill into depth only where their task needs it.
|
|
4
|
+
gate: {kind: explore}
|
|
5
|
+
rationale: >-
|
|
6
|
+
Scout results arrived as one-off prose in whatever shape each node improvised: parents could not hand a map forward, follow-up scouts started over instead of extending, and orchestrators reassembled transcripts by hand — one layer revision even prescribed cp-and-rename of scout reports. A single named artifact contract replaces all of that.
|
|
7
|
+
surfaces:
|
|
8
|
+
- on: boot
|
|
9
|
+
at: preview
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Exploration docs
|
|
13
|
+
|
|
14
|
+
An exploration doc is the durable form of a mapping result: `explore-<topic>.md`, flat in your context dir, shared by absolute path. An orchestrator's synthesis is `explore-map.md` — the high-level picture, with absolute-path pointers into the `explore-*.md` docs that carry depth.
|
|
15
|
+
|
|
16
|
+
Sections:
|
|
17
|
+
|
|
18
|
+
- **Scope** — one or two lines: what this maps and where the boundary sits.
|
|
19
|
+
- **The map** — the current state, organized by the subject's real seams (subsystem, layer, sub-question). Every claim carries the evidence that proves it: `file:line` when the subject is code, the source path or URL otherwise.
|
|
20
|
+
- **Pointers** — absolute paths to the exploration docs holding deeper detail, one line each naming what depth it holds. Omit when there are none.
|
|
21
|
+
- **Gaps** — what remains unmapped or unverified, stated explicitly so a reader does not mistake silence for verified absence.
|
|
22
|
+
|
|
23
|
+
Rules:
|
|
24
|
+
|
|
25
|
+
- When a task names an existing `explore-*.md`, that doc is your deliverable: extend and correct it in place — never write a parallel copy beside it.
|
|
26
|
+
- Current state only. Recommendations, diagnosis, target design, and narration of how the exploration proceeded all belong elsewhere; a doc that accumulates them stops being a map.
|
|
27
|
+
- These are goal-scoped working artifacts, not memory. A durable reusable truth uncovered while mapping still goes through the normal memory-capture path.
|