Commit graph

4 commits

Author SHA1 Message Date
Ouroboros
09ac51b2f0 acceptance packet / custody: durable omissions dispatch, custody-only settlement receipts, cross-process retirement lock, one packet budget
Fifth authoritative review: leading omissions and recaps with a durable
get_task_result reference are not_materialized_for_reviewer again (dispatchable,
non-resolving) — only source-less rows withhold the panel; contributor receipts
take agent-session settlement exclusively from the final custody replay, and a
missing or unreadable custody row is a typed mismatch instead of trusting the
response's self-report; the skill-history projection discloses rows scanned,
truncation, gap reasons and a canonical source, and an incomplete projection is
non-resolving; settlement publication and last-sibling retirement sit under a
stable project-digest file lock that holds across worker processes; the host's
late acceptance fields enter the packet builder before the single budget
enforcement; ARCHITECTURE names all four window-aware surfaces and documents
SETTLED before registration retirement. loop.py 282 903 bytes (−765). Manifest
untouched.

Co-authored-by: Ouroboros <311266734+ouroboros-agent@users.noreply.github.com>
2026-09-04 03:21:07 +03:00
Ouroboros
4a7fa18bee acceptance packet: partial sections never resolve, whole-record panel projection, bounded skill projection, serialized retirement
Third authoritative review (first with consistent receipts): a budget-truncated
repo_diff and a trajectory with omitted leading rows or recapped results were
still classified as resolving for API-only acceptance — both now carry explicit
incompleteness metadata and the vocabulary types them `partial`; the prompt
projection no longer ends in a hard slice — panels are projected as whole
records with an exact `records_omitted` count and the remainder goes through
disclosed truncation with a canonical `get_task_result` reference;
ARCHITECTURE/DEVELOPMENT map the new `state/skill_review_root_tasks.jsonl`
(producer, consumer, authority, retention, 20 MB threshold) and count seven hot
stores; the projection append is idempotent under a lock and acceptance reads it
newest-first, bounded (512 rows / 1 MiB, task-start cutoff); project retirement
is serialized by a striped per-project lock with custody re-read inside the
critical section (concurrent final siblings retire once); the shared trace
inventory recognises run_command/run_script with cwd=skill_payload and
delegate_start(root=skill_payload). delegate_custody.py stays at exactly 1 600
lines; manifest untouched (one regeneration at synthesis).

Co-authored-by: Ouroboros <311266734+ouroboros-agent@users.noreply.github.com>
2026-09-04 01:32:32 +03:00
Ouroboros
6a6db620cf acceptance packet: panels lead the prompt, partial rows never resolve, lifecycle from the canonical root; shared review projects retire once
Authoritative review round of P3: the acceptance-panel block was appended after
large review JSON and head-truncated away at 8 000 chars — it now leads the
bounded prompt and truncated reasons carry `reason_omitted_chars` plus a response
reference; a partial `tool_trajectory` section is typed `partial` (dispatchable,
never resolving for API-only acceptance reviewers); acceptance reads a compact
root-task→skill projection (`state/skill_review_root_tasks.jsonl`, appended by
terminal skill reviews, enrolled as a hot store) instead of every skill's whole
review history; skill-lifecycle identity keys are derived from the real skill
tool schemas (incl. toggle/publish and the `user_repo` bucket); lifecycle history
is read from the canonical root on split-root topologies.

Custody (AP10): a shared review project was never retired when the lowest run id
settled first and deferred — the last sibling to settle now attempts regardless
of order and one project-level PROJECT_RETIRED row discharges every sharer on
replay, so contributor receipts bind a consistent final settlement.
delegate_custody.py stays at exactly 1 600 lines. The size-ratchet manifest is
deliberately left untouched (one regeneration at synthesis).

Co-authored-by: Ouroboros <311266734+ouroboros-agent@users.noreply.github.com>
2026-09-03 23:21:08 +03:00
Ouroboros
1972be7850 acceptance: canonical mutation root and per-skill lifecycle facts
Two visibility gaps in the acceptance packet.

The mutation-attribution section was read from the EXECUTION drive while the
writer and the outcome consumer both resolve the canonical results root first.
On a split-root install the section silently vanished, with no absence marker to
notice. It now resolves `budget_drive_root` first, exactly like its sibling
resolver a few lines above.

Second, the panel never saw the lifecycle of the skills a task touched, so a
task that authored or repaired a skill gave the reviewer no way to tell whether
that skill actually reached a reviewed, ready, enabled state. The trace-touched
name scan moves out of loop.py into skill_readiness.py, where the readiness
predicate that consumes it already lives (loop.py keeps the historical private
name bound to it), and a new `acceptance_skill_lifecycle` joins those names with
any skill whose review history records this root task — which is how a
child-authored payload shows up at all. The scan also accepts the skill name
from `skill_review` / `skill_preflight` / `skill_exec` calls, because a free
delegation lane integrates a patch and never calls `write_file` or `edit_text`,
so those calls are the only carrier of the name in that shape.

The section is facts only, under the same visibility-only charter as
`substrate_execution`: no payload hashes, and nothing here gates a verdict.
Disclosed join gap: a UI or manual skill review carries no root task id and is
simply not joined.

Co-authored-by: Ouroboros <311266734+ouroboros-agent@users.noreply.github.com>
2026-09-03 18:49:07 +03:00