Repository navigation
Conversation
A decomposed child with workspace_kind=worktree and no explicit path got workspace_path=NULL. Dispatch then tried to anchor it on the board's default_workdir and, when the board had none, failed the spawn with 'no default_workdir set' — twice, tripping the failure-limit circuit breaker (live: t_ab2a7ce8, t_2dd0f5b7, 2026-09-02). The root of a decomposed callback graph is usually itself a dispatcher-materialized worktree <repo>/.worktrees/<root-id>, so the repo is recoverable from the root row: when the root path is a linked worktree checkout, stamp each pathless worktree child with the root's git common-dir parent (the main repo) as its explicit anchor. Children still get per-task worktrees (never the root's literal checkout), so sibling isolation is unchanged; a repo that can't be recovered keeps the anchorless row and the board-default dispatch path; scratch roots are untouched. Regression tests cover anchor inheritance + end-to-end child spawn resolution with no board default_workdir, the unrecoverable-root fallback, and scratch-root non-leakage.
A task whose title/body carries the durable PRODUCT_SIGNOFF marker defines its job as reporting back for human sign-off rather than driving to a terminal lifecycle transition. Repeated clean exits without one are a property of that workflow, so _account_protocol_violation now classifies such tasks at accounting time (read from the task row, so the exemption survives retries, reclaims, and dispatcher restarts) and never auto-blocks them — the violation is still recorded and the task retried, but the gave_up breaker never fires across any number of limit-reaching runs. Review round 1 correction for t_4067fdf1: the one-run PRODUCT_SIGNOFF test could not reach the breaker; it is replaced by a regression that drives the task through the full violation limit and proves it stays ready with no gave_up event, while ordinary coder/QA omissions keep their bounded retry/block behavior (covered by the existing limit test).
…wnership loss (c-027) heartbeat_fire_claim() collapsed fire-fence acquisition failure into False. During slow fenced delivery the worker's own heartbeat thread cannot acquire the same process-local RLock, so a successfully delivering run was misclassified as ownership loss and terminalled as 'Interrupted by shutdown before terminal completion.' (TrustMRR exec 4219b48d while RSI recovery exec f502e929 was settling). Tri-state contract: - True = renewed/confirmed owner - False = authoritatively inspected: owner mismatch / absent claim - None = fence unavailable/unconfirmed (contention or store error) - initial validation stays fail-closed: run starts only on exactly True - heartbeat loop: None rides the existing grace window (180s prod vs 30s fence wait); immediate cancel only on explicit False - post-run probes (_fire_claim_ownership_lost, both interrupted blocks, terminal owner-CAS read): None can never adjudicate a confirmed loss; uncertain outcomes get distinct ledger errors - mark_job_run also tri-state: None = fence unavailable (CAS never ran), False stays reserved for confirmed owner mismatch - _side_effect_fence unchanged: still the exactly-once save/delivery barrier Tests (all written red-first, verified failing on unfixed code): slow_owned_delivery (parent handoff), sustained fence-contention grace, pre/post-delivery None probes, grace-exhausted None probe, terminal write None, mark_job_run fence-unavailable None, RSI recovery dispatch fails closed during original's fenced delivery, TrustMRR slow-owned delivery terminal success. Managed-gateway restart E2E (systemd scope) passes on host: one gateway, single side effect, single delivery.
# Conflicts: # cron/jobs.py
alt-glitch
added
invalid
# Conflicts: # agent/agent_init.py # agent/system_prompt.py # cron/jobs.py # cron/scheduler.py # cron/scheduler_provider.py # hermes_cli/kanban_db.py # hermes_cli/web_server.py # plugins/cron_providers/chronos/__init__.py # tools/cronjob_tools.py
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
97ac4a6c5eb661cc963521cd9180db518cb28e01a5bf5ff66a93b81c9ec968fec625923db10e13f8Verification
Rollout guard
No merge. Managed gateway replacement remains gated on RSI
last_tick.jsonunix >1788535090.