Skip to content

Name stand-ins on stub results and validate impl markers (Z4, on #294) - #325

Draft
SamGu-NRX wants to merge 7 commits into
obv/burst14-bs-result-names-stand-insfrom
gpt-burst/1022z-bs-294-markers
Draft

SamGu-NRX wants to merge 7 commits into
obv/burst14-bs-result-names-stand-insfrom
gpt-burst/1022z-bs-294-markers

Conversation

@SamGu-NRX

Copy link
Copy Markdown
Owner

Zephyrus task Z4. Fixes the five open review threads on #294: stub runs never named their stand-ins, the runner published no markers, and the marker reader trusted each marker's stage.

Depends on #297 and Z3's branch gpt-burst/1022z-bs-297-stage-guard (d915427). This branch merges that branch in (3b69f2c) for the impl/<stage>.json marker writer in run_stage. Land #297 and Z3 first; until then this diff also shows their commits. The only conflict was graph.py, where both sides add "impl/" to the result inputs. I kept Z3's side.

What was wrong

  • graph.py:266: [obvious-fleet] Backend: the result names which stages ran as stand-ins #294 made the result stage read impl/, but nothing wrote the markers, so every stage came out unknown. [obvious-fleet] Backend: per-stage real selection with implementation markers #297's writer fixes that once merged.
  • compose.py:225: with HSS_ORCH_STAGE_STUBS on, the result stage is stubs/result.py, which never calls compose_result. So exactly the runs whose stages are stand-ins had no stageImplementations, no standIns and no reviewer-page notice.
  • compose.py:374: the reader took doc["stage"] on trust. A typo added a bogus key, and objects.json naming reads as a stand-in could be overwritten by reads.json saying real, which hid the stand-in.
  • compose.py:373: an implementation of [] or {} raised TypeError instead of impl_invalid, so the error lost the filename.

What changed

  • backend/server/result/compose.py:356 stage_implementations (was _stage_implementations) now refuses a marker with impl_invalid, naming the file, in three cases: its stage isn't a pipeline stage, its stage differs from the filename, or its implementation isn't the string real or stand-in. The caller now supplies the result stage's own entry through result_implementation. stage_impl_dir (:348) and stand_in_notice (:401) are shared with the stub.
  • backend/server/orchestrator/stubs/result.py:23: the stub result reads the markers through stage_implementations(..., result_implementation="stand-in") before it sends verdict_ready. It writes stageImplementations and standIns into result.internal.json and puts the same stand-in sentence on its review page. result.json is unchanged.
  • I didn't route the stub through compose_result itself, because that would replace the stub's fixed manual_review answer with a real composition over stub scene and verdicts. The stub shares the stand-in record, the marker validation and the page sentence instead.
  • review/template.html renders stand_in_notice. backend/docs/real-cpu-stages.md says what the result does with the markers.

Tests (backend/server/result/tests/test_stand_ins.py, backend/server/orchestrator/tests/test_stub_result_stand_ins.py)

  • A marker naming another stage, an unknown or missing stage, and a list or object implementation are each refused by filename.
  • A recomposition that finds an earlier impl/result.json still records the callable that is composing now.
  • A full stub journey records every stage except placement as a stand-in, result included, and names them on the review page.
  • A journey whose objects.json names reads fails the result stage with impl_invalid and sends no verdict_ready.

Command: cd backend && OMP_NUM_THREADS=1 .venv/bin/python -m pytest -q server/result/tests/test_stand_ins.py server/orchestrator/tests/test_stub_result_stand_ins.py

Full suite, run once. pytest-xdist isn't in the lock, so it ran without -n: cd backend && uv sync --locked && OMP_NUM_THREADS=1 uv run pytest -q gave 7 failed, 1561 passed, 16 skipped, 21 errors. None of these come from this change:

  • 14 errors in tests/test_capture_cold_restart.py (ImportError: cannot import name 'load_receipt' from 'scripts.replay_capture') and 4 failures in server/eval/tests/test_gates.py ('FAIL' == 'KNOWN_FAIL', dated pins). The same two files on 8057732 give the same 4 failed and 14 errors. This branch doesn't touch scripts/, tests/ or server/eval/.
  • 3 failures and 7 errors in tests/test_capture_real_downstream.py are TimeoutError in drain_finalize, with machine load around 20. Rerun on its own, the file passes.

uv run ruff check . passes. uv run ruff format --check . flags only server/orchestrator/tests/test_greptile_followup.py, which this branch doesn't touch.

Left: I didn't run the full suite on the parent branch, so the comparison above covers only the failing files. Nobody has reviewed this branch yet.

🤖 Generated with Claude Code

SamGu-NRX and others added 7 commits October 16, 2026 17:57
HSS_ORCH_REAL_STAGES names stages whose real implementations run even with
stage stubs on; the cpu alias covers every weightless stage and objects is
refused without HSS_OBJECTS_DEVICE=cpu. run_stage publishes impl/<stage>.json
under the pinned hss-stage-impl/v1 contract, and the result stage's inputs
carry impl/. Docs in backend/docs/real-cpu-stages.md.
HSS_ORCH_REAL_STAGES treated a missing or blank SMP_ENVIRONMENT as dev,
while Settings reads the same values as prod. An unconfigured production
process could therefore mix real and stand-in stages. Only an exact "dev"
now passes, matching Settings.

The remote refusal compared HSS_ORCH_MODAL_REMOTE to "1" only; load_orch
also accepts true/yes/on in any case. It now uses the same _flag parser.

The cpu alias no longer includes dense, which falls back to model weights
on photo-only packets, and is refused while VISION_EXTERNAL_CALLS is on,
since reads and criteria would then make paid calls.

The journey test now checks the markers the result stage receives in its
work dir, rather than filtering run.artifacts after the run.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…markers

Brings in the impl/<stage>.json marker writer from #297 (run_stage) and
the fail-closed stage selection from Z3, so the result stage has markers
to read. graph.py conflict: both sides add "impl/" to the result inputs;
kept the Z3 side, which also documents the marker contract.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stub runs never reached compose_result, so the runs whose stages are
stand-ins published no stageImplementations, standIns or reviewer-page
notice. The stub result now reads the markers through the composer
stage_implementations (with itself recorded as a stand-in) before it
sends verdict_ready, and shares the page sentence via stand_in_notice.

The marker reader now refuses a marker whose stage is not a pipeline
stage or differs from its filename, and one whose implementation is not
the string real or stand-in, with impl_invalid naming the file. Before,
objects.json naming reads could be overwritten by reads.json and hide a
stand-in, and a list or object implementation raised TypeError.

Fixes the open #294 threads at compose.py:225, :373 and :374.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Oct 22, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added the size:L 100-499 effective changed lines. label Oct 22, 2026
@SamGu-NRX

Copy link
Copy Markdown
Owner Author

@codex review

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 22, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ⚠️ Failed 2026-10-23T11:04:33.865197Z
We couldn’t complete this review. Comment @codex review to try again.
1079f60 Manual request
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@SamGu-NRX

Copy link
Copy Markdown
Owner Author

@codex review

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Something went wrong. Try again later by commenting “@codex review”.

An unknown error occurred
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L 100-499 effective changed lines.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant