# Compare a minimal Qoder coding runtime

## Traceability

- Spec ID: qoder-minimal-runtime-profile
- Status: Implemented

## Intent

Provide a named, evidence-bearing Qoder runtime profile that presents the model
with the same four fundamental coding tools as Pi while suppressing optional SDK
context sources. Let one harness comparison hold the task and composition fixed
while assigning different named runtime profiles to the baseline and candidate,
so a successful README artifact can test the profile rather than merely prove
that the SDK returned a result.

## Acceptance Scenarios

- AC-1: `QoderSdkExecutor` accepts `qoder-minimal-v1` and sends exactly `Read`,
  `Write`, `Edit`, and `Bash`, an explicit minimal system prompt, no filesystem
  setting sources, empty SDK selections for skills/plugins/extensions, no
  configured MCP servers, strict MCP isolation, an ephemeral session, and the
  existing bounded permission callback to the official Qoder Agent SDK.
- AC-2: The runtime receipt names the selected profile and records non-secret
  context-isolation facts without persisting the system-prompt body or any
  credential. Contradictory options that would weaken the named minimal profile
  fail before the SDK is loaded.
- AC-3: A `harness-compare.v1` manifest may explicitly assign a named Qoder
  profile to each variant. The comparison resolves the effective runtime per
  trial, records the profile in trial evidence, and permits both variants to use
  the same composition only when the profile assignment differs.
- AC-4: Existing manifests with no per-variant profile assignment retain their
  current tool set, runtime behavior, and validation policy. Their existing
  evidence fields remain intact, with `qoder-default-v1` added explicitly.
- AC-5: Deterministic tests prove profile forwarding, fail-closed validation,
  variant routing, and backward compatibility. A real SDK smoke runs the frozen
  README task once under each profile and grades the resulting file and changed
  file scope.

## Non-goals

- Replacing Qoder's qodercli/worker agent loop with a bare model loop.
- Implementing host-owned `read`, `patch`, or `run` MCP tools in this change.
- Claiming that one README trial establishes general coding quality or a
  statistically significant performance improvement.
- Changing the `.harness` grammar, adding a host adapter, publishing a package,
  or editing release metadata.

## Plan and Tasks

1. Add a public Qoder runtime-profile type and a frozen `qoder-minimal-v1`
   contract to the executor, including conflict validation and evidence fields.
2. Extend the additive `harness-compare.v1` manifest surface with explicit
   baseline/candidate profile assignment and resolve it per trial.
3. Add an isolated profile-comparison example that holds the grounded
   composition, fixture, prompt, grader, model, permissions, and trial order
   constant.
4. Add behavior tests and documentation for profile semantics and comparison
   limits.
5. Run focused package checks, repository gates, and one real SDK trial per
   profile; retain generated evidence outside the source tree.

## Test and Review Evidence

- AC-1/AC-2: the isolated staged checkout passed 56 package behavior tests. The executor test
  observes the exact four-tool SDK options, empty optional context sources,
  strict MCP configuration, cwd-bearing system prompt, prompt-free receipt,
  and fail-closed conflict validation.
- AC-3/AC-4: manifest and runner tests prove that an unchanged v1 manifest
  keeps `qoder-default-v1`, while the isolated profile experiment routes the
  same composition through six-tool default and four-tool minimal runtimes and
  records each profile in trial evidence.
- AC-5: a real Qoder SDK trial under each profile changed only `README.md` and
  passed all nine deterministic grader checks with score 100. After repairing
  missing cwd context found by the first smoke, both final trials completed in
  five turns with no permission denial. The observed credits were 12.449909 for
  default and 9.785649 for minimal; one trial is insufficient to claim a stable
  efficiency improvement, so the aggregate verdict remains `need_more_work`.
  The minimal init event exposed exactly `Bash`, `Edit`, `Read`, and `Write` as
  tools. It still inventoried installed skill metadata, which is not treated as
  proof that the files were absent; `skills: []` and the missing `Skill` tool
  are the bounded model-context/invocation evidence.
  Trial artifacts were retained outside the repository for local review and
  were not added to the package or source tree.
- Isolated staged-checkout verification: `harness:generated` and
  `harness:build` passed; all seven package test files / 56 tests passed; and
  the documentation link graph passed six checks. Earlier whole-tree gates also
  passed 94 root test files / 1,324 tests and root pack verification with 526 npm
  and 548 runtime-zip entries; those whole-tree counts include concurrent local
  work and are supporting evidence rather than the staged-slice proof.
- Verification qualification: the composite `npm run check` cannot report a
  zero exit while a concurrent, uncommitted DSL grammar change legitimately
  differs from `HEAD`, because `check:generated` rejects every generated diff.
  Its root-test stage passed, and all remaining stages were run individually.
- Risk: four tools may increase discovery attempts because `Glob` and `Grep`
  are hidden. The first smoke confirmed this risk when missing cwd context led
  to five denied path guesses; the repaired profile made the working directory
  explicit and the final smoke had no denials.
- Risk: filesystem settings and optional SDK resources can silently expand
  context. The executor sends explicit empty collections and strict MCP config,
  and the runtime receipt records those values.
- Risk: the working tree contains concurrent DSL sugar and compare-hardening
  changes. Final review must preserve them and distinguish their ownership from
  this profile slice rather than staging the complete dirty tree.