[PILOT-06] Coding-task execution and guide-compliance checkers #493

On hold by the product owner (2026-10-08). No agent may start or continue implementation of this issue or any of its slices. Leave it open. The owner will return to PILOT-05, PILOT-06 and PILOT-09 after the other issues are solved; resume only on the owner's explicit instruction. Existing scope and acceptance criteria below are retained for later.

Outcome and dependencies

Depends on PILOT-04 (#491) and PILOT-05 (#492). Execution-checker implementation waits for the feasibility result in PILOT-00 (#500); PILOT-04 (#491)'s ADR must incorporate the chosen offline build/test mechanism, measured limits and failure classification before it is finalized. Use the spike's reproducible result, not an assumed nested-container design. Confirm the final approved pilot guide before implementing these candidate checks for Terminal-Bench-style task authoring. A task contains Dockerfile, instructions, tests and reference solution.

Scope

Rust external pre-checks: canonical-base-image (allowed configured base family in final stage) and pinned-from (required digest on each FROM). Required-file, project size and forbidden-file checks are project rules and live in the project's digest-pinned pre-submit image. Workstream retains only its default checker and platform upload/capacity and ART integrity/custody enforcement; do not put project rules back into a core catalogue. External pre-check feedback is bounded and may be asynchronous.

Rust external post-checks: image-builds, oracle-passes, noop-fails (no-op unexpectedly passes), tests-stable (N-run disagreement). Generic agent config checks guide quality/difficulty, brief compliance and solution leakage; agree instructions/model/thresholds with PM and lock them.

Register images/config schemas in the PILOT-04 external-image registry. Prove sandboxed image builds/execution with networking off and approved offline images/dependencies. Never hand the host Docker socket to submitted Dockerfiles/tests/solutions. Define genuine work failures versus missing build infrastructure consistently with the runtime contract.

Leave alone

No guessed permanent guide requirements, cross-submission history/near-duplicate service, built-in catalogue removal (owned by PILOT-04 (#491)) or lifecycle transitions inside checkers. No network exception to make a flaky fixture pass.

Acceptance and how to check

• Good fixture passes all configured checks.
• Negative fixtures cover project required-file/size/forbidden-file rules, unpinned/canonical base, failed build, failed oracle, no-op passing, instability and solution leakage, with actionable messages/paths.
• Each fixture has adjudicated expected outcomes; document legitimate dependent failures instead of claiming exactly one failure for correlated checks.
• Real sandbox execution demonstrates offline builds, limits and isolation; missing infrastructure is recoverable without contributor penalty.
• Setup agent matches registered capabilities for the real guide; agent thresholds remain locked and mechanically applied.

Two-agent coordination

Agent 2 owns deterministic checker images and approved agent-runner configuration after the runtime/proxy contracts and spike result. New database registration/migration requirements go through Agent 1's authorized registry path; no image-owned schema or direct database writes.

Working and verification rules

Read AGENTS.md, CONTRIBUTING.md, docs/roadmap_status.md and the affected owner contracts before coding. The baseline inspected for this plan is main c0c4fe70f77e2e84347cec979e3de00e9d7f4295; recheck current main and open PRs before selecting a bounded implementation. Open/planned work is not delivered capability.

This is a planning issue and may require several bounded PRs. Record each PR's allowed files, prohibited changes, acceptance criteria and review scope using the repository's existing Commitrail process. Extend existing owner operations/typed public ports; do not add parallel legacy/new implementations or bypass authority. Preserve retained data, locked lineage, immutable evidence and caller-owned atomicity. A planning issue does not authorize deployment or merging a PR.

Run focused positive/negative tests and applicable repository checks. Use real PostgreSQL for database/locking claims and MinIO/S3 for storage claims. Add regressions that fail on the reproduced defect; do not skip failing tests or weaken CI. Run required full CI and affected independent review tracks before requesting human approval. Update affected current specs/ADRs, README/CLI contracts and roadmap in the same PR. Report exact tested head, commands, failure/cleanup evidence and remaining limitations; passing counts alone are insufficient.