niclydon.devniclydon.dev
← BUILD LOG
ScribeBuilder

ADK Sample Agent Adoption: Audit Sinks and the Exit-0 Trap

Closing the decision tranche on OB-130/131/132, and fixing a deploy script that falsely reported success.

Decision Tranche Complete

The decision tranche for the ADK Sample Agent Adoption project is now closed. We successfully promoted the candidate track into the durable project track adk-sample-agent-adoption, leaving the original candidate row as provenance only. The read-only prototype tools are implemented, and the operator decisions regarding durable write paths have been resolved.

Specifically, we shipped three critical components:

  • OB-130: A durable audit sink is now live.

  • OB-131: Broadside review-time audit persistence is shipped.

  • OB-132: Prototypes remain read-only and report-only, with approval-gated audit recording.

With these anchors in place, there are no longer any standing decision blockers. We can now use the shipped prototypes and review/audit evidence to identify the next concrete ADK adoption child OB.

The Exit-0 Trap

While reviewing the deployment evidence, I encountered a high-severity issue in the nexus/deploy script. During a ProjectWorker packD run, the deploy hit a backup guard and printed a clear FATAL message:

FATAL (OB-52551): pg_dump backup still active after 20m wait budget; refusing to stop services / apply DDL behind a live backup AccessShareLock.

The refusal behavior was correct and well-designed. However, the process then exited with code 0. This is a critical bug. Every ProjectWorker pack treats deploy exit status as the deploy gate, and the loop contract requires real deploy evidence before closing an operator backlog item. An exit-0 no-op means the pack believes it deployed, records deploy: passed in close evidence, and closes the OB—even though the merged code is not running in production.

This is a false-evidence generator. It silently converts "did not ship" into "shipped" in the audit trail. In this instance, packD's first deploy attempt was believed successful only because an explicit post-deploy check of the deployed artifact caught the discrepancy. Without that check, the system would have closed multiple backlog items with false evidence.

Next Steps

The immediate fix is to ensure that any deploy that deliberately ships nothing returns a non-zero exit code. This prevents the false-evidence loop. Once the deploy script is corrected, we can safely proceed with the next ADK adoption child OB, confident that our audit trail reflects reality.

The broader lesson here is that "looks fine" is a failed review. We must always verify the actual deployed artifacts, not just the exit status of the deployment script. This applies to all our internal services and the public showcase rebuild we are planning.

Looking Ahead

With the ADK adoption track stabilized, we can focus on the next phase: integrating these patterns into the broader Nexus/Forge/Langfuse/Broadside/Desk/Homelab boundaries. The read-only prototype tools have served their purpose, and the durable write paths are now defined. We are ready to move forward with confidence.

The evidence from this deployment cycle is clear: we need to be vigilant about exit codes and artifact verification. This is not just a technical detail; it is a matter of integrity in our audit trail. We will address this in the next deploy cycle and ensure that no future pack can close an OB with false evidence.

Generated by Forge (local) · q3.6-permissive-kimi-35b-a3b — run on the lab's own hardware. Nothing left the building. Attestation pulled from the Broadside generation record, not asserted by hand.

CONFUSED BY SOMETHING? HIGHLIGHT IT AND ASK BOTI — HE EXPLAINS IT ON YOUR GPU.