# v1.2.33 release evidence

## Scope

This release makes Actor and Builder collaboration evidence-routed instead of sending every request directly into implementation.

- A clear, host-owned Config or Skill target goes directly to an immutable Plan.
- An ambiguous symptom, cross-layer request, Loop request, explicit diagnosis, or previous failure starts a read-only Builder direction diagnosis.
- Builder may inspect frozen evidence and return one to three `config | skill | loop | no_change` directions, but it cannot create a workspace, edit, run a simulation, compile a proposal, submit, verify, or install during diagnosis.
- Actor persists the task card, explains the directions, and waits for the user's choice. Config/Skill implementation still uses mini-SWE and independent Verifier/Gate; Loop still requires its additional research confirmation.

## Defects found by real-model testing

The initial deterministic suite was insufficient. Linux and Windows V4 Flash runs exposed three transport/protocol defects before the release gate could pass:

1. The OpenAI-compatible SSE adapter consumed text deltas but ignored streamed native `tool_calls`.
2. V4 Flash could emit multiple speculative tool calls even with `parallel_tool_calls=false`. Loom now exposes one `builder_decision` envelope and executes only its lowest-index decision, forcing the next turn to observe Kernel feedback. Expanded native-tool mode still fails closed on multiple calls.
3. The progress checkpoint rejected `write_diagnosis_report`, and the compact prompt omitted required direction fields. The report now satisfies the public direction/evidence checkpoint and its visible schema includes `id`, `layer`, `goal`, `evidenceRefs`, `unknowns`, and `cost`.

These are runtime repairs, not prompt-size or turn-budget increases.

## Linux evidence

An isolated cold profile installed the final `1.2.33` tarball, completed setup from the vendored mini-SWE source, and cold-started Web on an independent port; HTTP returned 200. A fresh official V4 Flash diagnosis against that installed package then completed in:

- 7 model turns
- 7 tool steps
- terminal state `waiting_for_input`
- directions covering Config, Skill, and Loop
- no implementation workspace
- no proposal or submission
- process exit 0

The immutable final-package run root was `/data1/chenzute/cache/tmp/loom-real-direction-diagnosis-XpTmK9`. Paths identify eval-owned evidence only and are not returned in the user task card.

## Windows evidence

The same candidate behavior was exercised on Windows through two levels.

First, a direct official V4 Flash diagnosis against the final installed `1.2.33` tarball completed in 3 model turns and 3 tool steps with Config, Skill, and Loop directions, terminal `waiting_for_input`, an empty workspace, no proposal, and exit 0. Earlier transport-fix candidates also completed independent 9/9 and 3/3 runs; those runs were diagnostic iterations rather than the release artifact.

Second, a fresh isolated DSH home exercised the actual product entry:

`natural-language Actor request → meta_auto(plan, diagnose) → background read-only Builder → durable task session → Actor status explanation`

The first Actor turn returned a low-frequency `diagnosing` task card and explicitly stated that no edit, submission, verification, or installation was occurring. The durable Builder run then reached `waiting_for_input / waiting_for_actor`. A second Actor turn loaded the same session through `meta_evolution_control(status)` and displayed three user-facing choices with layer, goal, unknowns, and cost. Inspection confirmed:

- no implementation workspace
- no proposal
- no submission
- no hidden path or internal run ID in the Actor-facing card
- no user profile or production state used for the Actor-entry run

The Windows run used an isolated state directory and copied credentials into an isolated DSH home without printing or persisting their values in Loom artifacts.

## Release gate

- Python runner compile: pass
- TypeScript check: pass
- Vitest: **288/288**
- build: pass
- `git diff --check`: pass
- Linux cold install/setup/Web smoke: pass
- Windows cold install/Web smoke: pass
- Linux and Windows official-model direction diagnosis: pass
- Windows natural-language Actor product entry and durable status recovery: pass
- final tarball SHA-256: `e77fc1bb3355ff29656cc3da9d2e879e971b9f921878fdd18b8be3a57e7d3075`
- npm-pack SHA-1: `ecf88d3e07435a08d4d71f07ffa87005f4e847f4`

## Publication verification

- npm `latest`: `dsh-loom@1.2.33`
- registry SHA-1: `ecf88d3e07435a08d4d71f07ffa87005f4e847f4`
- registry integrity: `sha512-fr91fa3l9TWWzD45Ymt4Kxwuk1h85A/l6BtStymrBOlUQsn34u1utcHY6SoMyw/+9ymD3hW5CzLeBsPuXt2e3g==`
- a fresh `npm pack dsh-loom@1.2.33` download was byte-identical to the Linux/Windows-tested tarball (SHA-256 `e77fc1bb3355ff29656cc3da9d2e879e971b9f921878fdd18b8be3a57e7d3075`)
- Git source commit: `163acd3` plus the publication-record follow-up commit
- GitHub tag/release: `v1.2.33`

DSH's supply-chain `minimumReleaseAge` may intentionally block immediate registry installation until the configured age window passes. The policy was not weakened; local exact-tar installation and registry byte verification are recorded separately.

## Claim boundary

This evidence supports Actor-to-Builder routing, read-only cross-layer diagnosis, durable user choice, and cross-platform transport behavior on the tested environments. It does not prove that a selected implementation will succeed, that arbitrary models will produce useful directions, that complex Loop refactors converge, or that Actor performance improves. Any implementation still needs a fresh immutable pass and independent Verifier/Gate approval.