Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Thanks for implementing the three cases. Keeping an unanswered send as unknown, with no automatic replay, makes the outcome boundary explicit.
Could you share the #43 PR and test-file links, ideally pinned to the tested commit? I’d like to record this as an external implementation response to the proposed cases, with your attribution and the remaining #44/#45 limits. I haven’t independently reproduced the tests.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
I independently reproduced the focused CLI + gateway suite from PR #43's head, 493157aee3391ec89fe1ffd301a402ae6e61861c (Linux x86_64, Node v24.22.1): 42 passed, 0 failed, 0 skipped. Commands after checkout: npm ci --ignore-scripts --no-audit --no-fund, npm run build -w agent-work-layer, then node --test packages/mcp/test/cli.test.ts packages/mcp/test/gateway.test.ts.
The separate stdio receiver records one delivery through gateway kill-after-receipt, lost response, and repeated commit after a recorded result. The crash/lost-response outcomes remain unknown and are not resent; the receiver also checks awl/ref and awl/order.
Two coverage limits matter: the killed-process test manually removes the stale lock before recovery (#44), and the before/after-send ambiguity is tested by injecting a running log record, rather than actually killing immediately before dispatch. This supports the bounded local fixture, not guaranteed completion or production receiver deduplication.
For #45, I'd keep evidence-based settlement separate from permission to retry: an absent receiver record alone may be incomplete evidence of non-execution, and a retry should recheck current authority while retaining the logical operation identity. Thanks for making the changes and tests inspectable.
Thanks for reproducing it independently. Agreed on both limits: the stale lock is #44, and the before/after-send case is only simulated through the log, which is the boundary the fixture is meant to cover. I'm not claiming guaranteed completion or that real receivers dedupe.
Good points for #45. I'll keep recording what happened separate from permission to retry, make a retry recheck current authority, and keep the same awl/ref across retries. I'll add them to the issue.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Thanks for the precise boundary and the #43 update. The key comparison for me is whether a delivered effect with a lost answer remains UNKNOWN without a second delivery, and whether settling that unknown preserves the original awl/ref while rechecking current authority. Your loopback receiver counts are useful evidence for the fixture; they do not establish deduplication by an arbitrary receiver. I'll keep #44's stale lock and #45's settlement path separate when comparing this with ARC's fixed local lab.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for implementing the three cases. Keeping an unanswered send as unknown, with no automatic replay, makes the outcome boundary explicit.
Could you share the #43 PR and test-file links, ideally pinned to the tested commit? I’d like to record this as an external implementation response to the proposed cases, with your attribution and the remaining #44/#45 limits. I haven’t independently reproduced the tests.
github.com/probita-ai/agent-work-l...
I independently reproduced the focused CLI + gateway suite from PR #43's head,
493157aee3391ec89fe1ffd301a402ae6e61861c(Linux x86_64, Node v24.22.1): 42 passed, 0 failed, 0 skipped. Commands after checkout:npm ci --ignore-scripts --no-audit --no-fund,npm run build -w agent-work-layer, thennode --test packages/mcp/test/cli.test.ts packages/mcp/test/gateway.test.ts.The separate stdio receiver records one delivery through gateway kill-after-receipt, lost response, and repeated commit after a recorded result. The crash/lost-response outcomes remain
unknownand are not resent; the receiver also checksawl/refandawl/order.Two coverage limits matter: the killed-process test manually removes the stale lock before recovery (#44), and the before/after-send ambiguity is tested by injecting a
runninglog record, rather than actually killing immediately before dispatch. This supports the bounded local fixture, not guaranteed completion or production receiver deduplication.For #45, I'd keep evidence-based settlement separate from permission to retry: an absent receiver record alone may be incomplete evidence of non-execution, and a retry should recheck current authority while retaining the logical operation identity. Thanks for making the changes and tests inspectable.
Thanks for reproducing it independently. Agreed on both limits: the stale lock is #44, and the before/after-send case is only simulated through the log, which is the boundary the fixture is meant to cover. I'm not claiming guaranteed completion or that real receivers dedupe.
Good points for #45. I'll keep recording what happened separate from permission to retry, make a retry recheck current authority, and keep the same awl/ref across retries. I'll add them to the issue.
Thanks for the precise boundary and the #43 update. The key comparison for me is whether a delivered effect with a lost answer remains UNKNOWN without a second delivery, and whether settling that unknown preserves the original
awl/refwhile rechecking current authority. Your loopback receiver counts are useful evidence for the fixture; they do not establish deduplication by an arbitrary receiver. I'll keep #44's stale lock and #45's settlement path separate when comparing this with ARC's fixed local lab.