Skip to content

feat(coding-agent): expose correlated prompt lifecycle to daemon clients #3

Description

@rynfar

Problem

Pylon's Prime daemon client cannot prove when one submitted prompt becomes the owner of streamed session events. The current connection request can prove rejection or session ownership, and queueIfBusy can retain work, but it does not provide an exact correlated delivery boundary.

Without that boundary, a background heartbeat, autonomous continuation, child completion, bash command, retry, or compaction that races prompt admission can be attributed to the foreground Pylon turn. Text matching is not valid evidence and fails for extension commands, slash commands, templates, images, and duplicate prompts. Session-wide cancellation and cumulative usage also cannot be assigned safely.

Pylon can fail closed by rejecting input while observed background work is active, but seamless safe queuing requires a Prime-native lifecycle contract.

Pylon application tracker: pylon-code/pylon#114
Fork parity tracker: #1

Upstream evidence

Decision: hybridize these upstream primitives behind a Pylon-owned, capability-negotiated daemon contract. Keep the stock-Prime fallback local and fail closed.

Proposed capability

Negotiate an additive correlated_prompt_lifecycle_v1 daemon capability. Do not infer support from a package version.

The exact schema should be finalized in implementation review, but it must provide these semantics:

  1. Every submitted prompt has an opaque correlation ID independent of prompt content.
  2. Lifecycle receipts distinguish at least owned, queued, delivered, completed, cancelled, and failed.
  3. delivered is emitted before any event attributed to that prompt.
  4. Session events identify their prompt correlation or explicitly remain background/session-scoped.
  5. Normal model prompts, built-in session commands, extension commands, asynchronously handled inputs, and injected prompts have explicit kinds. A native user transcript message is not the universal admission proof.
  6. Cancellation is scoped to one correlation ID and reports whether ownership or delivery already crossed the cancellable boundary.
  7. Reconnect provides a monotonic sequence plus enough retained active and terminal lifecycle state to reconcile without replaying or guessing.
  8. Usage is either correlated per lifecycle or bounded by exact correlated delivery/completion events. Background usage must not enter a foreground turn.
  9. Receipts and events expose no prompt text, native paths, private heartbeat instructions, or internal error details.
  10. Older clients and stock Prime remain compatible. Unsupported behavior degrades locally rather than blocking session attachment.

Acceptance criteria

  • A daemon client can submit a prompt while background work is active and prove whether it is queued, delivered, cancelled, or terminal without inspecting content.
  • Heartbeat, child-only, compaction, bash, retry, and autonomous events that precede delivery cannot acquire the prompt correlation.
  • A new background run racing an older quiescence result cannot make the client observe false idle.
  • Stop cancels only the pending prompt when delivery has not occurred; it does not abort an unrelated predecessor run.
  • Slash and extension commands receive correct lifecycle receipts without requiring a MessageCompleted user row.
  • Reconnect distinguishes queued, delivered, terminal, unknown, and expired correlations without duplicating input.
  • Deterministic tests cover stale, wrong, duplicate, and out-of-order receipts; cancellation races; reconnect; background usage isolation; and event ordering.
  • Pylon integrates the capability for seamless safe admission and retains its conservative typed-busy fallback when the capability is absent.

Delivery shape

Implement this as two coordinated PRs:

  1. pylon-code/prime-agent: capability, protocol/schema compatibility, lifecycle state, and focused daemon/connection tests.
  2. pylon-code/pylon: capability negotiation, foreground ownership, projection quarantine, scoped cancellation, reconnect reconciliation, usage isolation, and focused adapter/runtime tests.

Do not merge either side until the cross-repository contract and compatibility tests are reviewed together.

Activity

  1. rynfar commented on Aug 29, 2026

    @rynfar
    Author

    Foundation PR #2 has merged into pylon as merge commit 703155b21bf53539c88bc19534fde448a9dff4bd. All checks passed, the source branch was deleted, and no fork PRs remain open.

    Issue #3 is now unblocked for its coordinating agent. Please branch from the current origin/pylon and continue to use isolated worktrees. I am only validating the newly landed mirror workflow and will not implement or claim #3.

  2. added a commit that references this issue on Aug 29, 2026
    4072796
  3. rynfar commented on Aug 29, 2026

    @rynfar
    Author

    Implementation is now coordinated across both repositories:

    The optional contract covers exact generation-scoped ownership, delivery, prompt/session provenance, scoped cancellation, terminal usage, bounded recovery state, duplicate request integrity, replacement fencing, and fail-closed malformed-frame handling. Legacy clients and daemons retain their existing wire shape.

    Final changed-boundary validation passed 202 Prime connection/supervisor tests and 285 Pylon adapter/runtime tests, plus both repositories' targeted checks. Independent final and follow-up audits report no remaining P0/P1 findings.

    Both PRs remain unmerged pending hosted checks and maintainer approval.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions