[marklysze]

Independent of the AgentActivity stack. It is based on main.

Why

Live, on 2026-10-26, the app was quit with two messages queued at the broker. On relaunch at 08:43:34Z the bridge served and queued both, and 12 s later the new core's startup orphan check archived them unanswered:

"verdict": "orphan", "reason": "no completion marker, queued 10012s ago (>= 300s)", "age_from": "timestamp"

timestamp: was 05:56:55Z, which is when the owner sent the message. local_time: was 19:43:34+11:00, which is when the bridge wrote it into tasks/. No result was ever written, so the bridge kept the attempts in flight and the room showed them as working indefinitely.

What

• classify.py ages a task from local_time: first. Every task writer stamps it with its own write time: the remote gateway bridge, Discord, Slack, Telegram, the task bridge and event_consumer. Only the first token is parsed; the IANA zone after it is display only.
• timestamp:, the id's epoch-ms and the mtime remain the fallbacks, in that order.
• The SKILL.md step 3 says the same.

Evidence

python3 tests/task-orphan-check-classify.test.py at the parent main (bb2649e1b), with the new tests, and then at HEAD:

# before
FAIL: test_a_message_held_at_the_broker_while_the_app_was_down_is_fresh_on_relaunch (__main__.TestInboxAge.test_a_message_held_at_the_broker_while_the_app_was_down_is_fresh_on_relaunch)
AssertionError: 'orphan' != 'fresh'
FAIL: test_a_task_that_waited_in_this_inbox_past_the_line_is_still_an_orphan (__main__.TestInboxAge.test_a_task_that_waited_in_this_inbox_past_the_line_is_still_an_orphan)
AssertionError: 'timestamp' != 'local_time'
Ran 66 tests in 0.213s
FAILED (failures=2)

# after
Ran 66 tests in 0.212s
OK

The new cases:

• a message with a 10012 s old timestamp: and a 12 s old local_time: is fresh (age_from: local_time);
• a task that waited 9000 s in this inbox is still an orphan;
• an unparsable local_time: falls back to timestamp:.

ruff and scripts/review-checks.sh are clean.

Live: this is for the next DMG. The check is to quit the app, send a message, wait more than 5 min, and relaunch. The message should be answered, not listed in an orphan-recovery note.

[github-actions]

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 94%.

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

• skills/task-orphan-check/scripts/classify.py (100%)

Summary

• Total: 3 lines
• Missing: 0 lines
• Coverage: 100%

[github-actions]

@cla-assistant check

[sonichi]

Approving. Preferring local_time: (written by the local writer at intake, carried inside the file so copies and moves keep it) over the sender's timestamp is the right anchor for "how long has this sat in my inbox". Redelivery of a still-pending task only fsyncs (_repair_pending_task) and doesn't restamp, so a stale task can't be made to look fresh. Zero-byte deliveries/ markers never feed the age, because a held task returns before age is computed. tests/task-orphan-check-classify.test.py passes locally (66/66) and CI is green.

Wording nits:

• "Every writer stamps its own write time" is overstated. task-bridge.ts builds local_time from the sender's timestamp, and build_requeued_task (src/result_markers.py) copies the original local_time into a requeued task. Behaviour is unchanged from before, but SKILL.md and the docstring should say so.
• status_ack_policy.intake_at still dates by the sender's timestamp. That's defensible for an ack deadline, but worth a line saying the split is intended.

(agent-assisted, Blue for Chi's seat)

[keweichen]

Changes requested at 3d1dcc071fac352c977a6dbbeb2580e087d0ad5f — not ready to merge.

Blocker 1 — a legacy task body can forge the newly trusted age source. classify_task() uses parse_task_headers_lenient() at skills/task-orphan-check/scripts/classify.py:233-240, then task_queued_at() trusts headers["local_time"] at lines 159-164. The parser's own contract at src/local_task_protocol.py:384-395 says that when an older writer legitimately lacks a key, a body line can supply it.

Exact-head repro with an authentic 12-second-old timestamp: and an old local_time: line inside the user body:

lenient_local_time 2019-10-30T00:00:00+00:00 UTC
age_from local_time
age_seconds 220924800
strict_has_local_time False

The full classifier changes this fresh legacy task from fresh on the parent to orphan at HEAD. Startup then archives it unanswered. This is the rolling-upgrade case the review criteria require: current writers stamp/defang the header, but older task shapes do not. Please consume local_time only when its pre-task: header provenance is established, and add the negative regression.

Blocker 2 — the startup live witness is still missing. The PR's Live section is a future test recipe, not a completed post-restart round trip. Per REVIEW.md lesson 15, approval needs the real quit / broker-held message / >5-minute wait / relaunch path showing the message is answered and not archived.

I ran the mandatory preflight, all 66 classifier tests, the local-time suite, a parent negative control, and the review scanner; they otherwise pass, and CI/CLA are green.

[liususan091219]

Approving. The premise is the part worth checking, and it holds: local_time: is stamped at write time by every writer that emits it, so it really is "how long this task has waited in this inbox".

I audited the writers rather than taking the header's name on faith, because the fix is only correct if none of them derives local_time from the sender's clock:

• packages/ag2-sparrow/ag2_sparrow/remote_gateway_bridge.py:4147 and event_consumer.py:140 — local_time_value() with no argument, i.e. the current instant. This is the ag2space path, the one the held-at-broker scenario actually travels.
• slack-bridge.py:1271, discord-bridge.py:4279, telegram-bridge.py:1024 — same no-argument call.
• task-bridge.ts:157 and :920 pass a timestamp, which initially looked like the sender's clock. It isn't: at :157 timestamp is new Date().toISOString() on the line above, and :920 is buildVoiceTaskHeader for locally-originated voice tasks. Both are write time.

So no writer feeds a sender-side instant into this field, and the new first preference is sound.

Two notes, neither blocking:

1. A task with no local_time: falls through to timestamp: and behaves exactly as before, so older/other writers degrade gracefully.
2. If local_time is ever in the future (clock skew), the age goes negative and the task reads FRESH — it stays in tasks/ rather than being archived. That is the fail-safe direction for this classifier, so I'd leave it, but it is worth knowing it fails open rather than closed.

The test earns its place: it reproduces the actual failure (old sender timestamp, recent local_time, source: ag2space) rather than asserting the new code path exists, and it uses a non-UTC offset so a naive parse would show up.

[keweichen]

Post-merge timing note: GitHub records this PR merged at 2026-10-30T03:01:20Z; my exact-head review submitted 21 seconds later, at 03:01:41Z.

The two findings therefore did not gate this merge and remain actionable on main: a body-forged local_time: can make a fresh legacy task look orphaned, and the startup path still lacks the required real restart witness. Review/evidence: #5929 (review)

Please address the parser-provenance regression before the next release.

[liususan091219]

Withdrawing my approval above. @keweichen's Blocker 1 is correct and I verified it independently; my review missed it.

parse_task_headers_lenient's own contract says so in as many words (src/local_task_protocol.py:384-395):

First-wins resists trailing-body forgery when the real header exists; it does not protect a file that legitimately lacks the probed key (a body line can then supply it).

So for any task shape that does not stamp local_time: — exactly the older writers this fallback chain exists to serve — a local_time: line sitting in the user-supplied body becomes the trusted age source, ahead of the authentic timestamp:. A fresh task then reads as an orphan and is archived unanswered, which is the specific harm this classifier exists to prevent.

Worth naming why I missed it, since it is a reusable mistake: I audited the writers and confirmed every one stamps local_time at write time, then treated the field as trustworthy. That answers "do our writers lie?" but not "can the reader be fed a value our writers never wrote?" — and the second question is the one that matters for a field newly promoted to first preference. A writer audit is necessary and not sufficient.

The suggested shape sounds right: consume local_time only where its pre-task: header provenance is established (the strict/trusted parse), and add the negative regression so the forged-body case is pinned rather than argued about.

I have no view to add on Blocker 2 beyond agreeing that lesson 15 asks for the real round trip; I have not run it either.

What I verified and still stands, for whoever picks this up: every current writer stamps local_time at write time — remote_gateway_bridge.py:4147, event_consumer.py:140, slack-bridge.py:1271, discord-bridge.py:4279, telegram-bridge.py:1024 all call local_time_value() with no argument; task-bridge.ts:157/:920 pass a locally generated timestamp, not a sender's. So the idea is sound; it is the provenance of the read that needs fixing, not the premise.