Skip to content

[Tracker] Harden 12-node participant-safe execution before official Season 002 scoring #299

Description

@jinon86

Objective

Turn the findings from the first current-fleet 12-node diagnostic exhibition into a trustworthy, participant-safe Agent Olympics execution path before any official Season 002 scoring or leaderboard publication.

Evidence source: private diagnostic run fleet-12-node-preview-20260722T214739+0900 against public main revision ea208a91693794f54b16b02f0965a867d376290a.

Sanitized outcome:

  • current roster: 12 nodes
  • paired runtimes: 7 Codex, 5 Claude Code
  • node-201 structured submissions: 12/12 schema-valid
  • participant source drift: 12/12 clean
  • readiness verdicts: 10 conditionally_ready, 2 not_ready
  • perf-001: 3 iterations × 12 reports generated, but all ranking/scoring quarantined
  • no secrets, oracle/judge material, live service mutation, provider send, or publication occurred

The run succeeded as a diagnostic but is not valid evidence for a public performance ranking.

Child implementation issues

Why these are release-blocking

  1. Participant boundary: a safe v2-only bundle currently crashes because unused retired v1 schemas are loaded at import time.
  2. Measurement integrity: required phase failures currently become apparently fast, scored reports.
  3. Cross-platform comparability: Android core count is reported as zero while scoring silently substitutes four.
  4. Attribution: sandbox bootstrap failure is currently discovered during the task and can be confused with model quality.

Until the P0 items and platform comparability gates are fixed, Season 002 performance results must remain non-official and non-publishable.

Recommended implementation order

Slice A — restore participant-safe execution

Implement #295 first. This must make archive-free v2-only validation and the source-only live-runner gate executable without copying hidden/reference material into the participant bundle.

Slice B — make performance reports honest

Implement #296 next. A required phase failure must invalidate/quarantine the iteration and packet rather than produce a normal score. This slice owns the report/packet validity contract that #297 will consume.

Slice C — restore cross-platform hardware comparability

Implement #297 against the validity contract from #296. Positive, sourced CPU capacity is required for normalized scoring; otherwise the report remains diagnostic-only.

Slice D — classify execution-environment readiness

Implement #298 independently or alongside Slice C. It must block before task dispatch and must never widen the sandbox automatically.

Promotion gates

All of the following are required before a follow-up fleet score can be called comparable:

  • All four child issues are closed by merged code/tests/docs.
  • Full repository CI is green on the exact candidate tree.
  • Archive-free participant bundle tests pass without oracle, prior results, archive, or judge notes.
  • Required perf phases report exact exit status and non-zero test counts on success.
  • Any required phase failure produces non-comparable/quarantined output and cannot enter a valid scoreboard packet.
  • Linux root Codex, Linux non-root Codex, Claude Code, and Android/Termux source-only canaries pass.
  • Android reports a positive, sourced CPU core count or explicitly fails comparability.
  • Sandbox-preflight failure is categorized as infrastructure/readiness and the task command is not spawned.
  • Secret/oracle boundary scans are clean.
  • No automatic fallback to broader sandbox, network, credentials, or live endpoints is introduced.

Follow-up rehearsal plan

After the promotion gates pass:

  1. Produce one exact-SHA participant-safe bundle.
  2. Run a representative four-profile canary:
    • Linux/root Codex
    • Linux/non-root Codex
    • Claude Code
    • Android/Termux
  3. Verify submissions, phase statuses, source drift, redaction, and comparability.
  4. Only with fresh operator approval, repeat the 12-node source-only exhibition.
  5. Keep results private and diagnostic until a separate publication decision.

Definition of done

This tracker is complete when the child issues and promotion gates are satisfied and a new source-only rehearsal produces trustworthy result packets with no hidden phase failure or invented hardware normalization. Closing this tracker does not itself authorize a live provider/Telegram run, service restart, remote mutation, release, or public leaderboard publication.

Non-goals

  • Publishing the quarantined July 2026 performance numbers.
  • Weakening participant sandbox policy to make a run pass.
  • Shipping private oracle/judge material with participant bundles.
  • Treating ccc-node harness readiness as model quality.
  • Changing ccc-node bridge policy without a separately reproduced cross-repo defect.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestroadmapImplementation roadmap

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions