@nurix/etna 0.20.49 → 0.20.50

package/data/harness-index.json

@@ -1,5 +1,5 @@
 {
-    "fingerprint": "cc18c2845819",
+    "fingerprint": "1e7b6e289709",
     "harnesses": {
         "code": {
             "plugin": "code",

package/data/harnesses/code/CLAUDE.md

@@ -142,7 +142,7 @@ The single policy for sub-agent dispatch — when to fan out, at what tier, and
 
 - **Delegate to keep bulk out of the main context.** Wide file reads, sweeps, broad research, audits, fixture prep — work whose raw tool output the main session doesn't need — defaults to a sub-agent: output a sub-agent reads dies with it, while output read inline fills the main context and brings its compaction closer, which is where a long session loses what it knew. **Tokens are not the constraint — assume them abundant.** Never trim a read, a check or a verification to save them; the main context's capacity is what delegation protects. The hand-off is self-contained (the sub-agent sees none of the conversation); run independent delegations in parallel.
 - **The policy binds every agent, not only the main session.** A sub-agent doing build work inherits these defaults with the dispatch capability to honor them (Runtime Notes): it dispatches its own sub-agents for work this policy routes off-thread — the bookkeeping drain, a wide read — instead of absorbing it into its own loop. What never delegates (a gate verdict, browser driving, the pins the drive earned) never delegates at any level.
-- **Every dispatch carries a goal, milestones, a budget and a progress file.** The brief names the result that ends it, its intermediate milestones in order, and a wall-clock budget derived from the work — a run of n browser journeys is n × 10 s, a build step is what its last run took plus half again — and tells the sub-agent to append one line per milestone to `/tmp/<task>-progress.log` (`<UTC time> <milestone> <started|done|stuck> — <one-line result>`), before and after anything expected to run past two minutes. The dispatching agent checks that file on a schedule matched to the budget — a background monitor or a timed check, never a blind wait — and when a milestone overruns its budget it looks at the transcript, the process list and the log, then unblocks the sub-agent with a message, stops it, or takes the step over. An overrun never passes unread. Both failure modes this replaces were observed in one program run: sub-agents that stalled for an hour with nobody watching, and a main session that then redid the dispatched work inline, losing the parallelism the dispatch existed for.
+- **Every dispatch carries a goal, milestones, a budget and a progress file.** The brief names the result that ends it, its intermediate milestones in order, and a wall-clock budget derived from the work — a run of n browser journeys is n × 10 s, a build step is what its last run took plus half again — and tells the sub-agent to append one line per milestone to `/tmp/<task>-progress.log` (`<UTC time> <milestone> <started|done|stuck> — <one-line result>`), before and after anything expected to run past two minutes. The dispatching agent checks that file on a schedule matched to the budget — a background monitor or a timed check, never a blind wait — and when a milestone overruns its budget it looks at the transcript, the process list and the log, then unblocks the sub-agent with a message, stops it, or takes the step over. An overrun never passes unread. Both failure modes this replaces were observed in one program run: sub-agents that stalled for an hour with nobody watching, and a main session that then redid the dispatched work inline, losing the parallelism the dispatch existed for. A sub-agent a workflow started is answered through the workflow, never by message: a message to it starts a second copy beside the one still running, and the two then write the same files. Fix the shared state it reported, or stop the workflow and re-run it.
 - **Parallel plans cascade into each other.** Running several plans of one program at once, each on its own branch, pays only when the cascade is planned for. Every merge into `dev` moves the base under every open branch, so an open pull request re-merges `dev` before its CI run is worth waiting on — a run on a stale base spends twenty to forty minutes proving nothing. The append-only files every plan writes (the changelog index, the backlog, project memory) conflict on every merge and resolve as a union, in priority order where the file is ordered; a re-merge re-runs the typecheck and the touched suites before its push. Parallel load is a fault of its own: a suite run beside several building sub-agents times out tests that pass alone, so a timeout in a file the plan does not touch is re-run alone before it is called a defect.
 - **Small or judgment work stays inline.** A task finishable in a handful of tool calls is faster done than briefed. **Never delegate judgment by reflex** — a second opinion is for a high-stakes call or an explicit request.
 - **A delegated result is a report, not verifiable ground truth** — verify load-bearing results directly.

package/data/harnesses/code/harness.json

@@ -29,5 +29,5 @@
     "origin": "https://cdn.nustack.io",
     "track": "latest"
   },
-  "digest": "393786214dd0"
+  "digest": "7bf99a09b133"
 }

package/data/harnesses/etna/CLAUDE.md

@@ -155,7 +155,7 @@ When a plan's implementation surfaces work that is important but outside the pla
 The single policy for sub-agent dispatch — when to fan out, at what tier, and how far to trust the result. Component-internal dispatch mechanics (the foreman loop, the brainstorm twin, batch classification) stay in their components and defer here for anything this section covers. No dispatch mechanism ⇒ inline.
 
 - **Delegate to keep bulk out of the main context.** Wide file reads, sweeps, broad research, audits, fixture prep — work whose raw tool output the main session doesn't need — defaults to a sub-agent: output a sub-agent reads dies with it, while output read inline fills the main context and brings its compaction closer, which is where a long session loses what it knew. **Tokens are not the constraint — assume them abundant.** Never trim a read, a check or a verification to save them; the main context's capacity is what delegation protects. The hand-off is self-contained (the sub-agent sees none of the conversation); run independent delegations in parallel.
-- **Every dispatch carries a goal, milestones, a budget and a progress file.** The brief names the result that ends it, its intermediate milestones in order, and a wall-clock budget derived from the work — a run of n browser journeys is n × 10 s, a build step is what its last run took plus half again — and tells the sub-agent to append one line per milestone to `/tmp/<task>-progress.log` (`<UTC time> <milestone> <started|done|stuck> — <one-line result>`), before and after anything expected to run past two minutes. The dispatching agent checks that file on a schedule matched to the budget — a background monitor or a timed check, never a blind wait — and when a milestone overruns its budget it looks at the transcript, the process list and the log, then unblocks the sub-agent with a message, stops it, or takes the step over. An overrun never passes unread. Both failure modes this replaces were observed in one program run: sub-agents that stalled for an hour with nobody watching, and a main session that then redid the dispatched work inline, losing the parallelism the dispatch existed for.
+- **Every dispatch carries a goal, milestones, a budget and a progress file.** The brief names the result that ends it, its intermediate milestones in order, and a wall-clock budget derived from the work — a run of n browser journeys is n × 10 s, a build step is what its last run took plus half again — and tells the sub-agent to append one line per milestone to `/tmp/<task>-progress.log` (`<UTC time> <milestone> <started|done|stuck> — <one-line result>`), before and after anything expected to run past two minutes. The dispatching agent checks that file on a schedule matched to the budget — a background monitor or a timed check, never a blind wait — and when a milestone overruns its budget it looks at the transcript, the process list and the log, then unblocks the sub-agent with a message, stops it, or takes the step over. An overrun never passes unread. Both failure modes this replaces were observed in one program run: sub-agents that stalled for an hour with nobody watching, and a main session that then redid the dispatched work inline, losing the parallelism the dispatch existed for. A sub-agent a workflow started is answered through the workflow, never by message: a message to it starts a second copy beside the one still running, and the two then write the same files. Fix the shared state it reported, or stop the workflow and re-run it.
 - **Small or judgment work stays inline.** A task finishable in a handful of tool calls is faster done than briefed. **Never delegate judgment by reflex** — a second opinion is for a high-stakes call or an explicit request.
 - **A delegated result is a report, not verifiable ground truth** — verify load-bearing results directly.
 - **Tiers**: mechanical fan-out → the cheapest capable tier; judgment-heavy delegation → the session's standard tier; the strongest tier **only** on explicit user request. The session itself defaults to the standard tier, entering the strongest only by explicit user switch. Model names live in Runtime Notes.

package/data/harnesses/etna/harness.json

@@ -14,5 +14,5 @@
     "origin": "https://cdn.nustack.io",
     "track": "latest"
   },
-  "digest": "5ef5fa9f9472"
+  "digest": "eb29fb639903"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nurix/etna",
-  "version": "0.20.49",
+  "version": "0.20.50",
   "description": "Bootstrap a project with a Nurix harness — writes the committed contract (CLAUDE.md, AGENTS.md, .claude/harness.json, settings.json, the mount hook) and mounts the harness itself, gitignored, from a bundled payload; sessions keep it current from the CDN.",
   "type": "module",
   "bin": {
@@ -46,5 +46,5 @@
     "agent",
     "plugin"
   ],
-  "etnaFingerprint": "cc18c2845819"
+  "etnaFingerprint": "1e7b6e289709"
 }