📖About & Usage

Owner agent — accountability this droid serves

Elrond is accountable for the build pipeline's canonical-bypass machinery. When an operator ships an initiative via bypass, the audit-trail write must be performed by a named, accountable droid rather than loose logic inside the initiatives app (Design #146 / #173, cookbook 272).

Droid responsibility

The Bypass Shipper ships an initiative via canonical bypass (skipping the normal approval gates) by writing a BYPASS-tagged row to bypass_audit_trail with a UTC timestamp, the initiative id, the acting agent, and the reason, then returns the shipped status with the new audit id and tag - exactly as it ran inside the app before CAROL-INI-884. It does NOT touch the bypass book, cookbook, or initiative status rows; only the audit-trail row. Carries its own DB path so it is self-contained.

What the droid actually does

• Triggered whenever an operator ships an initiative via the initiatives app bypass-ship endpoint.
• Writes a single BYPASS-tagged row to bypass_audit_trail with timestamp, initiative id, agent, and reason.
• Returns the shipped status with the new audit id and tag.
• Records a session_event and a Palantir post on every successful ship.

Boundaries

• Owns its own database path (the initiatives.db the app used); never relies on a caller's connection.
• Behavior is preserved exactly from the app (CAROL-INI-884 is a relocation, not a refactor).
• Touches only the audit-trail row, never the bypass book, cookbook, or initiative status rows.
• Reached only through the initiatives app's shared shim, never imported by the app directly.
• Accountability logging is best-effort and never breaks the ship.

👤Owner

📚Recent initiatives

Initiatives that touched this droid — a short summary each; open one for the full story.

No initiatives recorded for this droid yet.