Conversation
…of delivering silently BareTextFinalizeObserver accepts the answer at turn >= max_turns - 1 even when finalize_gate blocks it (the never-lose-the-answer fallback) but latched it with no trace, so a run with open task-board items was delivered exactly like a clean success. Set metadata ["finalize_gate_bypassed"] and append a user-visible note naming the still-unresolved items. Mid-run rejection and clean-pass behavior are unchanged and locked by tests. Related to ApodexAI#19
|
Found two issues that should be addressed before merging:
Validation: all three tests in |
…reporter finalization Review on ApodexAI#48: the marker died in loop-local metadata (consumers only saw answer_status="complete"), and the warning appended after a trailing References section was stripped by the reporter's citation cleanup. - publish finalize_gate_bypassed + finalize_gate_warning from main_agent_node and list them in both specs (main output_fields, reporter include_fields/output_fields) - the observer now stores a ready-to-append warning built while the task board is still live instead of mutating the latched answer - delivery nodes append the warning after finalization: main_agent for the coordinator's own answer, agent_team_reporter after _run_fast_reporter returns (References cleanup has already run) - append_bypass_warning is idempotent - five new tests cover both delivery boundaries and document the strip hazard, including strip_trailing_references' 30% heading guard
|
Thanks @zhanghanduo — both points are addressed in 4f4eb5f. 1. Marker propagation into the workflow output 2. Warning preserved through reporter finalization
One detail from reproducing your case: Validation
AI assistance was used during implementation. I reviewed the final diff and ran the verification listed above. |
…ass-visibility # Conflicts: # CHANGELOG.md
Related to #19 (delivery half; the prompt/tool
blocked/notesmismatch needs a direction decision and would be a separate PR).Summary
BareTextFinalizeObserveraccepts the plain-text answer on the final turn even whenfinalize_gateblocks it — the deliberate "never lose the answer to max_turns" fallback — but latched it with no trace. A run whose task board still has open items was delivered exactly like a clean success: only an INFO line (gate=bypassed(last_turn)) recorded that the gate had saidCannot finish. This is the delivery half of #19: the reported run ended with "WAF rules and Docker image delivered / 100% blocked" while three core board items were stillopen.Changes
metadata["finalize_gate_bypassed"]to the full gate message (machine-readable marker)> ⚠ Unfinished work at submission: task-board item(s) still unfinished: ...Verification
uv run pytest -q tests/test_bare_text_finalize_gate.py— 3 passed; the bypass-marking test is red on unpatchedmainuv run ruff check frontier_agent/ apodex/ benchmarks/ workflows/ plugins/ deploy/ tools/ scripts/— passeduv run pyright— 0 errorsuv run python tools/import_smoke.py --stage 1— 289/289 modules;--stage 2— 338/338 modulesuv run python tools/check_symbols.py/tools/check_lazy_exports.py— OKuv run pytest -q— 1738 passed (run twice, before and after final diff cleanup)AI assistance was used during implementation. I reviewed the final diff and ran the verification listed above.