Cortex Actions
Status
Section titled “Status”First-party addon shipped with arka-deck. Current registry is static / first-party; no active third-party marketplace.
| Field | Value |
|---|---|
| Manifest | addons/cortex-actions/manifest.json |
| Entrypoint | addons/cortex-actions/src/index.ts |
| Maturity | beta |
Cortex Actions exposes a chat panel for selectable catalogue blocs that frame the next agent turn. A selected bloc is prepared for the next user message as agent-ready content, rendered in TOON and injected from the local project runtime.
Favorites are hydrated local-first through Cortex Lite. arka-deck first resolves the atom by sourceId in the local graph; the public Cortex is used only when the local atom is missing or incomplete, and the fetched content is then synchronized back into Cortex Lite before it can become runtime input. The runtime never injects only an MCP address or remote pointer.
Agent action cards also surface runtime choices produced during orchestration: preparing ArkaDoc tasks before dispatch, approving dispatch, retrying after QA or asking for arbitration. Dispatch approval cards only target ready ArkaDoc task documents assigned to worker roles (owner or contributor); QA assignments are excluded from dispatch targets. Cards are keyed by session/run so repeated refreshes do not create duplicates.
Surfaces
Section titled “Surfaces”| Surface | Location |
|---|---|
| Project options | <project>/.arka-deck/addons/cortex-actions.json |
| Execution logs | <project>/.arka-deck/cortex-actions/{year}/{month}/exec_*.json |
| Project favorites | <project>/.arka-deck/cortex-actions/favorites.json |
| Declared worker | cortex-favorites-suggester |
| Runtime cards | Project route /api/projects/:id/agent-action-cards |
Events listened / published
Section titled “Events listened / published”- Listen: chat events relevant to catalogue bloc selection before a turn.
- Publish: recorded selection, Cortex Actions execution, favorite suggestion.
Boundaries
Section titled “Boundaries”The public panel does not expose governance modes, profiles, atoms or documents as user-selectable runtime surfaces. It consumes Cortex surfaces already wired in the composition root, does not dynamically load third-party code and does not turn the internal registry into a public marketplace.
Runtime cards do not bypass Mission Guardian. Selecting a dispatch card still submits a runtime command, and the command can be refused by the mission gates.
Going further
Section titled “Going further”- Formal addon contract: ../extension/contrat-addon (coming)
- “Write an addon” tutorial: ../extension/ecrire-un-addon (coming)