3.2 KiB
| id | date | status | supersedes | superseded-by | affected-paths | affected-components | migration_confidence | migration_source |
|---|---|---|---|---|---|---|---|---|
| 0023 | 2026-07-10 | Accepted | medium | docs/memory-system/03-architecture-decisions.md### ADR-023 — Backlog process management ships as a new `os-backlog` plugin (not an os-vault extension) |
0023 — Backlog process management ships as a new os-backlog plugin (not an os-vault extension)
Context
The Planka backlog pilot (vault note vault-backlog-pilot-plan) reached its plugin phase with one gated decision open: build the AI's process-management surface (skills for capture/list/tick/board ops, deterministic scripts over the planka-api gem, card-triage/board-audit named agents, hooks) as a new plugin or as an extension of os-vault. The decision also surfaced a broader framing question: what cc-os is relative to ~/dev/cc-plugins.
Decision
(1) New global plugin os-backlog (plugins/os-backlog/). os-vault is not extended. Naming per cc-os-plugin-skill-naming-convention.md: verb-first skills invoked as /os-backlog:<verb>; no name: frontmatter; no commands/ dispatchers. (2) Ecosystem role made explicit: cc-os is the user's personal operating layer for Claude Code — the family of always-on, globally installed, mutually aware os-* plugins running on every machine; ~/dev/cc-plugins is the shelf of optional, as-needed plugins. Cross-plugin awareness and cooperation (including notifications, ADR-024) is an explicit long-term goal of the cc-os family, not an accident.
- Rationale: Separation of concerns — os-vault is the memory/knowledge domain (what do I know), os-backlog is the workflow/process domain (what state is work in): different backing stores (SecondBrain vault vs. Planka Postgres via REST), different failure modes (local files vs. network service), different maturity (os-vault is eval-hardened and stable; backlog skills will churn while the process settles). Every comparably sized domain in the family already got its own plugin (os-adr, os-status, os-doc-hygiene). Hook hygiene: a broken/unreachable Planka must not degrade vault sync hooks.
Consequences
Backlog process management (capture/list/tick/board skills over Planka) ships as a new, separate os-backlog plugin rather than extending os-vault, keeping the memory/knowledge domain and the workflow/process domain on different backing stores with different failure modes and maturity levels. This also makes explicit that cc-os is meant to be a family of mutually aware, cooperating always-on plugins, with cross-domain needs met by skills invoking each other rather than by merging plugins.
Alternatives rejected
Extending os-vault — the only benefit is one fewer plugin to maintain, a cost already amortized by bin/refresh-plugins and the marketplace procedure (ADR-018); it would couple a churning surface to a frozen, eval-tuned one and blur the domain boundary the tag taxonomy itself encodes. Future skills needing both domains compose by invoking each other's skills, not by merging plugins.
- Cross-references: vault notes
vault-backlog-pilot-plan(pilot plan + execution status),cc-os-plugin-skill-naming-convention; ADR-018 (install procedure); ADR-024 (notification direction the plugin will consume).