Carol — back to Apps ← Apps

Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaDroidsInitiative Retrigger
Initiative Retrigger

Initiative Retrigger

Droid Runs the retrigger orchestration that files a follow-on of a blocked/closed initiative after the pipeline is fixed
Go to droid →

📖About & Usage

Owner agent — accountability this droid serves

Elrond is accountable for the build pipeline's retrigger machinery. When an operator retriggers a blocked/closed initiative, the orchestration that files the follow-on must be performed by a named, accountable droid rather than loose logic inside the initiatives app (Design #146 / #173, cookbook 272).

Droid responsibility

The Initiative Retrigger files a follow-on (-FF) of a blocked or closed parent initiative after the pipeline has been fixed (INI-342): it loads the parent, runs the INI-725 blocked-parent remediation gate (refusing with a structured 409 unless override_blocked_parent_gate is set), parses the parent title, builds the retry intent, routes it through the Author plus Validator orchestrator (iv-s1, falling back to ia-s1) to create the follow-on, then auto-enqueues the new follow-on (INI-624) so the autonomous resume loop completes end-to-end - exactly as it ran inside the app before phase 4. Carries its own DB handle and title parser so it is self-contained.

What the droid actually does

  • Triggered whenever an operator retriggers an initiative through the initiatives app retrigger endpoint.
  • Loads the parent initiative and runs the INI-725 blocked-parent remediation gate before doing anything else.
  • Returns a structured 409 result (never an HTTP response) when the gate refuses and no override is given.
  • Builds the retry intent from the parent's scope plus any operator note, then routes it through the Author plus Validator orchestrator to create the -FF follow-on.
  • Auto-enqueues the new follow-on so it does not sit in planned-but-undispatched limbo.
  • Records a session_event and a Palantir post on every successful retrigger.

Boundaries

  • Owns and closes its own database connections; never relies on a caller's connection.
  • Behavior is preserved exactly from the app (phase 4 is a relocation, not a refactor) modulo the async-to-sync transform: the droid runs synchronously and the thin endpoint awaits it in a thread.
  • Never raises an HTTP response; the gate 409 is carried back as a structured result and the thin app endpoint reconstructs the 409.
  • Reached only through the initiatives app's shared shim, never imported by the app directly.
  • Does not touch the bypass book, cookbook, or initiative status rows beyond what the original orchestration did.

👤Owner

Elrond · Head of Engineering

📚Recent initiatives

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

No initiatives recorded for this droid yet.