Harness Platform M5: choosing not to add another runtime

01 / MILESTONE DECISION

M5's most important output is a boundary it did not add.

Harness Platform reached its conditional polyglot review with plenty of correctness evidence and no profile that attributed a production-shaped bottleneck to Node. The engineering result was restraint: keep TypeScript on Node ≥ 22, record what evidence is missing, and make the decision explicitly reversible.

That is not a consolation prize. A second runtime adds build systems, dependency and supply-chain policy, deployment images, observability joins, incident ownership, data contracts, and often a serialization or FFI seam. M5 required those costs to buy a measured improvement. The repository could not make that case, so it refused the change.

M5 — Polyglot review (conditional)
goal
└── add a second runtime only for a hard, measured,
    attributable M3–M4 bottleneck

evidence found
├── deterministic offline correctness tests
├── golden evaluations and typed event contracts
├── observability seams
├── injected HTTP/process boundaries in M3
└── injected PostgreSQL/object-store boundaries in M4

qualifying evidence not found
├── representative workload or SLO
├── repeated latency percentiles or throughput
├── CPU/memory attribution to a limiting hot path
├── causal separation from I/O, algorithms, and dependencies
└── controlled runtime comparison

decision
└── retain TypeScript on Node ≥ 22; add no runtime or service boundary

02 / WHAT COUNTS AS EVIDENCE

A green test suite can locate a regression. It cannot locate a runtime bottleneck.

M3 tests the OpenAI-compatible provider and Docker-plan boundaries with injected HTTP and process executors. M4 tests PostgreSQL and S3-compatible behavior with injected protocol fakes. Golden scenarios, typed events, and OpenTelemetry bridges make behavior observable and refactorable. Those are valuable correctness and instrumentation contracts.

None of them supplies a representative demand model, a service-level target, repeated latency percentiles, sustained throughput, or CPU and memory attribution. Even the elapsed time of pnpm test mixes hundreds of tests, process startup, temporary repositories, SQLite work, local sockets, and test-runner overhead. It cannot identify a production component, much less prove that its runtime is the constraint.

evidence class                 present?   what it establishes
────────────────────────────  ─────────  ─────────────────────────────────────
offline tests                 yes        deterministic correctness contracts
golden scenarios              yes        behavior against known fixtures
typed events + OTel seams     yes        places where measurement can attach
whole-suite CI duration       yes        elapsed time for the entire command
representative workload       no         no production-shaped demand model
latency percentiles           no         no repeated component distribution
throughput study              no         no sustained work-rate result
CPU / memory attribution      no         no runtime hot-path evidence
runtime comparison            no         no controlled alternative baseline

03 / CONDITIONAL LANGUAGE GATE

The architecture asks for causation before it pays for polyglotism.

A slow endpoint may wait on a model provider, database lock, object store, network hop, algorithm, data structure, garbage collector, or CPU-bound loop. Rewriting the component before attributing the delay can preserve the real bottleneck while adding a new one at the boundary between runtimes.

The recorded M5 gate therefore moves from workload to attribution, from attribution to attempted remedies, and only then to total boundary cost. A reference implementation in another language or a team preference is not a substitute for any step.

reopen M5 only when a new task manifest includes

1. workload
   name · environment · repetitions · target/SLO · baseline

2. attribution
   latency percentiles or throughput + CPU and memory evidence

3. causation
   rule out I/O, external dependencies, data structures, algorithms,
   and document the Node-side remedies already attempted

4. boundary economics
   show a specific second runtime materially improves the target after
   build, deployment, security, observability, and ownership costs

04 / MACHINE-READABLE DECISION

The review itself ran as a four-path task contract.

M5 was not a broad refactor disguised as an architecture review. Its manifest allowed exactly four paths: the architecture decision, project status, roadmap, and the manifest itself. Network and Git push remained denied, filesystem writes required approval, model and tool budgets were finite, and the delivery type was a pull request.

id: m5-polyglot-review
goal: audit M3–M4 evidence and retain Node unless profiling justifies otherwise

allowed_paths:
  - ARCHITECTURE.md
  - README.md
  - ROADMAP.md
  - tasks/m5-polyglot-review.yaml

permissions:
  fs.read: allow
  fs.write: ask
  network: deny
  git.push: deny

budget:
  max_model_tokens: 60000
  max_tool_calls: 100

delivery:
  type: pull_request

The public M5 diff confirms that boundary: four changed files, 99 insertions, eight deletions, and no runtime source, dependency, package, service, or deployment seam. The implementation began at e9308b9, was refreshed after the exit-gate fix, and merged at 4bf5f68.

M4 merge
d3b2859a48cfb794472d30805ea91b47dc1086d0
        ↓ separate Step 0 hardening merged first
ee759486a2af9abbbe37ac7763b8c9152b794cf8
        ↓ M5 refreshed head · pull request #4
85342e35ecaa2a83a947f3c67dc9ff08133a2b7d
        ↓ four automated checks green
4bf5f68701dee38eecdc0830c4f1be0d937d3942
M5 merge

authoritative PR #4 diff
4 files changed · 99 insertions · 8 deletions

runtime source files changed   0
new services                   0
new dependencies               0
new language boundary          0

05 / STEP 0 AUDIT

The language review exposed a more urgent problem: the exit gate trusted too much.

After the first M5 decision pass, the development record returned to Step 0's original promise: take one task manifest, modify its branch, run tests, and produce a structured report. The repository already had the directory structure, events, fake model, policy, and reports. The missing part was whether that end-to-end result could be trusted under an adversarial change.

Step 0 exit-gate audit

1. branch identity
   existing task branches were not necessarily checked out;
   free-form branch metadata could be trusted

2. path scope
   only working-tree status was checked;
   committed changes and writes left by tests could escape

3. failure evidence
   manifest and early Git failures could exit before a report existed

4. policy attribution
   passing decisions and task/session/run provenance were incomplete

5. integrated bootstrap proof
   no deterministic manifest → Pi adapter → edit → tests → report flow

1. 01

   Branch labels could describe state they did not prove

   Existing task branches were not always selected, unrelated branches could pass, and a caller-supplied label could stand in for the checked-out commit. The fix derives one branch from the canonical manifest and verifies the Git identity.

2. 02

   A clean worktree could hide an out-of-scope commit

   Status-only scope checking saw staged, unstaged, and untracked work but not the committed delta from the task base. It also did not check again after tests. The new gate evaluates the complete sampled delta on both sides of execution.

3. 03

   The earliest failures could escape without evidence

   Invalid manifests and Git preflight errors occurred before normal report construction. A strict preflight artifact now records those attempts; later stages use run-report/v2 with an ordered failure trail.

4. 04

   Policy decisions needed causal identity

   Allow, ask, and deny outcomes now carry task, session, run, action, subject, effect, and reason. The report validator rejects current events whose attribution does not match the attempt.

5. 05

   The Pi-shaped bootstrap existed only as pieces

   The hardening task added one TaskAgent seam and a production upstream Pi adapter, then proved manifest → branch → adapter → edit → tests → report with an injected agent and a spawned protocol fixture in the offline lane.

06 / TRUSTED EXIT GATE

The fix binds identity, scope, execution, and the final evidence receipt.

The audit fixes were intentionally isolated in their own task and pull request #3. Local operation now creates or selects exactly tasks/<id>. Detached CI accepts one trusted tuple: branch label, checked-out head object ID, and base object ID. The manifest is rechecked as a canonical regular file with the same digest throughout the run.

canonical tasks/<id>.yaml
  → derive exact tasks/<id> branch
  → local: select that branch
    CI: verify head ref + immutable head SHA + immutable base SHA
  → attest repository, Git metadata, manifest, HEAD, and merge base
  → sample committed + staged + unstaged + untracked + relevant ignored delta
  → enforce allowed_paths before builder
  → optional TaskAgent builder (upstream Pi adapter or injected test agent)
  → re-attest identity and enforce scope
  → parse one approved test executable plus argv; never invoke a shell
  → stop ordinary descendants and enforce scope again
  → persist causal events
  → atomically commit run-report/v2 and its run.recorded receipt

Scope now includes committed changes relative to the verified base, staged and unstaged entries, ordinary untracked files, relevant ignored writes, raw tracked bytes, file type, executable mode, and both ends of a rename or copy. The same policy runs before and after the builder and tests. Evidence paths are reserved regardless of a broad manifest glob.

pnpm harness run tasks/m5-polyglot-review.yaml \
  --ci-head-ref tasks/m5-polyglot-review \
  --head-sha 85342e35ecaa2a83a947f3c67dc9ff08133a2b7d \
  --base-ref ee759486a2af9abbbe37ac7763b8c9152b794cf8

07 / ATTESTABLE RUN EVIDENCE

A pass now has to agree with its branch, delta, tests, failures, and receipt.

Historical run-report/v1 remains readable for old UI and eval data, but it is not accepted as current gate evidence. A normal attempt uses run-report/v2, which requires a run ID, exact task branch, coherent policy result, Git attestation, current event attribution, and reportWritten. An invalid manifest or early Git failure uses run-preflight-report/v1 because a complete normal identity cannot yet be trusted.

{
  "schema": "run-report/v2",
  "status": "passed",
  "branch": "tasks/m5-polyglot-review",
  "policy": {
    "changedPathsOk": true,
    "changedPaths": [
      "ARCHITECTURE.md",
      "README.md",
      "ROADMAP.md",
      "tasks/m5-polyglot-review.yaml"
    ],
    "violations": []
  },
  "tests": {
    "command": "pnpm test",
    "exitCode": 0,
    "ok": true,
    "durationMs": 16940
  },
  "git": {
    "mode": "ci",
    "headSha": "85342e35ecaa2a83a947f3c67dc9ff08133a2b7d",
    "baseSha": "ee759486a2af9abbbe37ac7763b8c9152b794cf8",
    "preTest":  { "policyPaths": 4 },
    "postTest": { "policyPaths": 4 }
  },
  "deliverables": { "reportWritten": true }
}

The normal report is written to a same-directory temporary file, synchronized, and atomically renamed. Its serialized events include one matching run.recordedreceipt only for the path whose bytes were committed. If the preferred write fails, the runner records that failure and verifies a fallback; if every destination fails, it may return validated in-memory evidence, but it cannot claim delivery or exit successfully.

08 / ADVERSARIAL HARDENING

Every new guarantee attracted a bypass attempt.

The first five fixes established the shape of a trustworthy gate. The longer hardening pass then attacked the assumptions underneath it: path normalization, Git plumbing, filesystem identity, command parsing, process cleanup, streaming budgets, and evidence persistence. This is why the companion diff is much larger than M5 itself.

surface                    hardened behavior
─────────────────────────  ──────────────────────────────────────────────────
manifest path/mutation     canonical regular file; digest checked during run
branch and base            exact identity; immutable CI tuple; metadata recheck
committed or ignored write included in the sampled task delta
rename/copy                source and destination both enter policy evaluation
clean filters/file mode    raw bytes, type, and executable mode checked directly
shell chaining             command parsed as one executable + argv; operators fail
builder edits then throws  mutation still audited before structured failure
test writes after success  post-test scope gate can still block delivery
evidence path/symlink      reserved outputs; unsafe links and inode swaps rejected
report write failure       typed failure, verified fallback, or in-memory evidence
policy events              allow/ask/deny carry task, session, run, and subject

Two legitimate repository artifacts also exposed the danger of an overbroad detector: a checked-in MCP fixture under a node_modules-shaped path and Vitest's hashed cache. The final rules narrow operational exemptions instead of either blocking known fixtures or ignoring an entire class of task-created files.

The gate also treats failure trails as ordered evidence. If tests fail and the final scope check finds an illegal write, both survive. If a builder edits the repository and then throws, the mutation is still audited. If evidence persistence or report commit fails, a previous success cannot remain the terminal claim.

09 / TWO CHECKS-GATED PULL REQUESTS

Hardening merged first; M5 had to prove itself on the stronger base.

Pull request #3 merged the Step 0 hardening as ee75948. The M5 branch was then refreshed to 85342e3, so its new run report was produced by the hardened gate rather than inherited from the earlier implementation attempt. Pull request #4 merged only after the exit gate and three CodeQL statuses were green.

pull request #3 — M0 exit-gate hardening
├── implementation: c5f920f87271b02f241ae39609376c75ee192748
├── merge:          ee759486a2af9abbbe37ac7763b8c9152b794cf8
├── public diff:    22 files · +7,908 / −541
└── CI + CodeQL:    green

pull request #4 — M5 conditional polyglot review
├── implementation: e9308b92a20adc4a49c889e110c58a4571c81a05
├── refreshed head: 85342e35ecaa2a83a947f3c67dc9ff08133a2b7d
├── merge:          4bf5f68701dee38eecdc0830c4f1be0d937d3942
├── public diff:    4 files · +99 / −8
└── exit gate + CodeQL analyses: four green checks

This is checks-gated delivery, not a peer-review claim. The public PR record shows successful automated analysis and merge chronology but no approving human review.

10 / VERIFIED RESULT

The final evidence supports the decision process and the gate—not performance.

The M5 PR-head workflow ran on Node 22 with a frozen lockfile, passed strict TypeScript, all 535 deterministic tests in 36 files, the golden scenario, and the hardened M5 exit gate. Its report recorded the same four allowed paths before and after tests, no violations, the verified head and base objects, and a committed report receipt.

A separate publication audit cloned the exact merge at 4bf5f68, installed the frozen lockfile under Node 22.19.0, and reproduced 535/535 tests, a clean strict typecheck, and the one golden scenario. This validates the repository state used by the article without turning the website task into a new Harness release.

public PR-head evidence · GitHub Actions 33446082649
├── strict TypeScript                  passed
├── test files                         36 / 36
├── offline correctness tests          535 / 535
├── golden scenarios                   1 / 1
├── changed paths before tests         4
├── changed paths after tests          4
├── path-policy violations             0
├── run-report/v2                      passed · reportWritten=true
└── automated PR checks                4 / 4 green

independent publication audit · exact merge · Node 22.19.0
├── clean-checkout tests               535 / 535
├── strict TypeScript                  exit 0
└── golden scenarios                   1 / 1

The PR-head exit-gate run and CodeQL workflow passed before merge. The later main CI run and CodeQL run also passed; by workflow design, the task-specific exit gate belongs to the PR branch and is skipped on the main push.

11 / CURRENT TRUTH

M5 closes a roadmap decision while keeping its trust boundaries visible.

The accurate description is evidence-gated single-runtime architecture with a hardened, sampled host exit gate. It is not a Node performance result, an atomic filesystem monitor, a security boundary against privileged concurrent writers, a live Pi provider test, or preventive containment for untrusted code.

12 / FILE GUIDE

The decision, gate, evidence, and residual trust each have an inspectable home.

13 / WHAT WOULD REOPEN THE GATE

The next runtime discussion should begin with a workload, not a language.

1. 01

   Name the production-shaped demand

   Define the operation mix, payloads, concurrency, environment, repetitions, and an explicit latency, throughput, cost, or memory target.

2. 02

   Retain raw profiles and repeatable results

   Store profiler output, test configuration, timestamps, environment identity, and result artifacts so another run can challenge the attribution.

3. 03

   Fix the cheapest cause first

   Test batching, backpressure, caching, data structures, algorithms, database and object-store behavior, provider latency, and Node-native remedies before a rewrite.

4. 04

   Propose one narrow boundary

   If attribution survives, compare one specific seam and include serialization, deploy, supply-chain, observability, on-call, and ownership cost in the result.

5. 05

   Move untrusted building into preventive isolation

   The host exit gate is a detective control over repeated samples. Use the Docker sandbox-runner when concurrent writers, child processes, host secrets, or network access must be prevented rather than discovered afterward.

14 / EVIDENCE LEDGER

Public implementation claims resolve to two pull requests and one pinned merge.

• M5 merge 4bf5f68 — the source pin for the final decision, hardened base, tests, and documentation.
• Pull request #4 — M5 conditional polyglot review — authoritative four-file diff, check results, and merge chronology.
• M5 task contract and architecture decision — the evidence threshold, no-go result, limitations, and reopening criteria.
• Pull request #3 — Step 0 exit-gate hardening — the separate 22-file trust-gate change prompted by the audit in the same development record.
• M5 pull-request evidence run — 535 tests, 36 files, one golden scenario, four pre/post policy paths, zero violations, and the uploaded run-report/v2 artifact.
• Publication audit — an independent clean checkout of the exact merge under Node 22.19.0 reproduced all 535 tests, strict TypeScript, and the golden scenario. The private development conversation supplied chronology and audit prompts only; it is intentionally not published as implementation evidence.