32 lines
3.2 KiB
Markdown
32 lines
3.2 KiB
Markdown
|
---
|
||
|
|
id: "0023"
|
||
|
|
date: 2026-07-10
|
||
|
|
status: Accepted
|
||
|
|
supersedes:
|
||
|
|
superseded-by:
|
||
|
|
affected-paths: []
|
||
|
|
affected-components: []
|
||
|
|
migration_confidence: medium
|
||
|
|
migration_source: "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).
|