From 7835241dbbff4e01fe1a7f236ccec49c37f4d6c9 Mon Sep 17 00:00:00 2001 From: "itarun.p" Date: Tue, 14 Jul 2026 00:03:59 +0700 Subject: [PATCH] docs: record native spawn correlation boundary --- docs/prompts/meta-loop-validation-prompt.md | 11 ++++-- docs/runbooks/tools/meta-loop.md | 39 +++++++++++++++++++++ 2 files changed, 48 insertions(+), 2 deletions(-) diff --git a/docs/prompts/meta-loop-validation-prompt.md b/docs/prompts/meta-loop-validation-prompt.md index 1985952..60e2d55 100644 --- a/docs/prompts/meta-loop-validation-prompt.md +++ b/docs/prompts/meta-loop-validation-prompt.md @@ -34,9 +34,16 @@ Verify and report: only on the lock mtime and does not verify owner identity or process liveness - the managed-attestation boundary: confirm-spawn records operator metadata; it does not prove or execute a native worker spawn +- the native-correlation boundary: later session metadata or an observed + subagent-activity child ID is audit evidence only. It does not bind that child + to a particular dispatch at spawn time. Keep native work at no more than + three children per wave unless the runtime returns a direct child ID or a + documented causal, replay-safe event contract has passed a live scenario. Do not call an unwrapped native spawn managed or verified by this tool. Do not print secrets, tokens, private paths, private issue links, or provider bridge -details. Do not treat the lock as ownership-safe across untrusted users or -hosts. If a check is skipped or cannot be proven, say so plainly. +details. Do not treat an event candidate, polling result, or later metadata as +a dispatch-time native-correlation contract without that scenario evidence. Do +not treat the lock as ownership-safe across untrusted users or hosts. If a +check is skipped or cannot be proven, say so plainly. ``` diff --git a/docs/runbooks/tools/meta-loop.md b/docs/runbooks/tools/meta-loop.md index 2d0ae66..0e35a6c 100644 --- a/docs/runbooks/tools/meta-loop.md +++ b/docs/runbooks/tools/meta-loop.md @@ -107,6 +107,42 @@ Use opaque, non-sensitive attestation labels. Do not put tokens, command output, private paths, or provider-specific credentials in an attestation or `--result` value. +## Native Spawn Correlation Boundary + +The control ledger is not a native-runtime correlation adapter. A native child +identifier must be bound to the exact dispatch before it can be used as a +release gate for higher fan-out. The following evidence is useful for a later +audit, but is not that binding: + +- a ledger attestation; +- an application-server spawn-event candidate that has not passed a live + causal and replay-safety scenario; +- later session metadata, polling output, or local activity history; or +- an observed subagent-activity child identifier with no direct dispatch + binding. + +In the verified Codex 0.144.1 boundary, neither the available application- +server spawn-event candidate nor later metadata established a safe +dispatch-time native-correlation contract. Do not infer the missing binding +from timing, task text, worker names, or a session identifier. A session +identifier may support post-run token or activity audit, but is not a native +child identifier for dispatch control. + +Keep native work at no more than three children per wave while this boundary +holds. Do not raise that cap until one of these conditions is demonstrated in a +harmless live scenario on the target runtime: + +1. The native spawn API returns the child thread identifier directly; or +2. A documented event contract provides a causal, replay-safe binding from the + dispatch to exactly one child thread identifier. + +For either condition, pre-subscribe before the spawn when events are used, then +prove the expected parent and dispatch binding, one-to-one child mapping, +bounded delivery time, and safe failure on missing, duplicate, late, or +mismatched identifiers. A mock-only test, a later history query, or a child ID +seen after the fact cannot replace this scenario. If the evidence is absent or +ambiguous, hold the high-fan-out wave and retain the cap of three. + ## Single-Writer Lock And Stale Recovery Every command that writes a ledger uses `.lock` as an exclusive, @@ -174,6 +210,9 @@ finish - [ ] Each recorded spawn and return has an explicit, non-sensitive attestation, with independent evidence retained outside the ledger when needed. +- [ ] Any proposed native fan-out above three has a direct child-ID return or a + documented causal, replay-safe event contract that passed the live + scenario described above; otherwise the wave is held. - [ ] No active worker remains before synthesis. - [ ] The ledger is synthesized, finished, and preserved or removed according to the task's retention policy.