8. Understand Foundry's role

Foundry is the engineering control plane. Codex authors/investigates as an assigned worker; it does not replace Foundry's assignments, supervision, evidence, or review gates. The EHR is the vehicle for evaluating that process across languages.

The vocabulary

An interactive session is not itself a launched runtime. A READY workstream is not proof that code is unimplemented, and it is not proof that acceptance passed. Report the observed state and its limits rather than inferring success from labels.

Project history

Backend code exists on stacked candidates. The closure evaluation branch preserves an intentional removed-guard regression and its repair. The regression made the domain closure test fail, while database guards still prevented persisted closed writes. Restoring the domain guard repaired it. See CLINICAL_RESULT.md for exact candidates/events.

Older readiness/bootstrap documents intentionally retain historical observations such as “not scaffolded yet.” They are evidence history, not current feature status.

Inspect before acting

Use the reviewed CLI setup from lesson 1:

"$MINIEHR_FOUNDRY_PYTHON" -m foundry status
"$MINIEHR_FOUNDRY_PYTHON" -m foundry recover
"$MINIEHR_FOUNDRY_PYTHON" -m foundry task show EHR-4
"$MINIEHR_FOUNDRY_PYTHON" -m foundry workstream show EHR-4 frontend --json
"$MINIEHR_FOUNDRY_PYTHON" -m foundry session list --json

Session metadata does not expose tokens. Do not print credential-file contents or paste tokens into chat. Do not end every task session merely because recovery lists stale activity; inspect whether another worker is still using them.

Assign and attribute work

An authorized orchestrator creates/assigns the workstream, declares owned paths, and mints a session. Use the CLI's --help for exact options. This tutorial has EHR-4/tutorial, role frontend, ownership README.md and docs/tutorial/**, and interactive session as-a58d314b943f. It is authored on agent/frontend/ehr-4-tutorial, based on the frontend candidate. No documentation runtime is claimed.

If source changes exceed ownership, arrange the proper assignment first. Never edit .foundry/state/ manually: the CLI owns that versioned state. Human owner registration, policy signing, and merge approvals remain human actions.

Run full tests through Foundry

For an assigned agent with its own valid, private env file, export the session variables without printing them. Replace the example file path with that agent's actual credential file:

set -a
source /absolute/private/path/to/your-session.env
set +a
"$MINIEHR_FOUNDRY_PYTHON" -m foundry test \
  --full --base main --evidence --task EHR-4 --json

This assumes PYTHONPATH and MINIEHR_FOUNDRY_PYTHON were set as in lesson 1 and that the current checkout is the candidate you intend to evaluate. Do not use another agent's identity to claim authorship. If credentials expire, use the normal session lifecycle; do not disable enforcement.

Foundry's configured dotnet preset restores/builds, lists tests, runs the full solution with TRX reports, and reconciles identities. Its JSON records candidate commit/tree, target main commit, executable/SDK, config digest, command, counts, scope, and problems. Read exit status and evidence together.

The underlying command is dotnet test MiniEHR.slnx --logger trx --results-directory <results>, where Foundry supplies the report directory. This is an explanation of the executed command, not an instruction to bypass supervision. Do not disguise .NET commands as Python tests to pass an evidence validator.

Three different meanings of validation

Structural Foundry validation checks configuration/control-plane consistency. Application tests check executed behavior. Full evidence additionally checks scope, provenance, and correspondence between discovered and executed cases. Structural validation alone cannot establish that C# behavior is correct.

At application candidate 0d4d28b, dotnet exited 0 with 58 passes and one readiness skip. Foundry exited 1: scope incomplete, 23 listed identities unmatched. Discovery output interleaves project banners; this preview can assign names to the wrong assembly. The fail-closed refusal is preserved, not suppressed.

Remaining platform gaps

FOUNDRY_GAPS.md is the detailed repair handoff:

• Reliable full-solution discovery attribution is blocking accepted evidence.
• Failure summaries can lose actual counts/SDK metadata.
• Task-level full validations are not properly surfaced in status/workstreams.
• Temporary machine reports are deleted, limiting later investigation.
• Native Windows ingestion and targeted C# selection are not established.
• Default container availability does not prove a reviewed .NET worker boundary.

MiniEHR's observed execution uses the owner-authorized logical host boundary. A separate SDK image smoke is not proof MiniEHR ran in that image. No autonomous C# builder/repair agent or independent review is claimed from this interactive authoring session.

Recovery and acceptance

After a lost connection, inspect status/recover, uncommitted work, known commits, sessions, artifacts, and runtime logs. Preserve existing work; close a disconnected session through the CLI and create an attributable replacement when appropriate. Sandbox failure can append state before a Git commit fails: inspect before retrying, and let the CLI complete recovery instead of hand-editing records.

Acceptance still requires repaired full evidence at the final candidate, appropriate independent reviews, and human integration approval. Publishing a GitHub candidate or a static preview is not main merge approval. Docs commits change the tree and cannot borrow a prior candidate's tests as fresh evidence.

Checkpoint

Why can 58 passing cases coexist with Foundry exit 1? Behavior passed, but this preview could not establish complete discovery/result identity correspondence.

Next: Troubleshooting and glossary.