PRD: os-backlog plugin — the AI's process-management surface #9

New Issue

Closed

opened 2026-07-10 17:10:52 +00:00 by jared · 2 comments

jared commented

2026-07-10 17:10:52 +00:00

Owner

PRD: os-backlog plugin — the AI's process-management surface

Phase-1 PRD deferred by the backlog pilot plan (vault: vault-backlog-pilot-plan); plugin home decided in ADR-023. Drafted 2026-07-10.

Problem Statement

Task and process state is now live in Planka (pilot gate passed 2026-07-09), but the AI has no formal surface for it. Sessions don't know where a project's tasks live (Planka board? Forgejo issues? in-repo markdown files?), don't reliably capture work discovered mid-session, and have no convention telling them how autonomously to act on a given task. The human ends up as the router: repeating "where do I look for tasks" decisions per project, manually shepherding cards, and never being sure the board reflects reality. Three trackers exist with no written boundary between them, and nothing deterministic tells a session which one is in effect for the repo it's sitting in.

Solution

A new global os-backlog plugin that makes tracker routing deterministic and task behavior conventional:

One boundary rule, written down and injected: Planka owns task state (the default for all work); git issues (Forgejo via tea for private repos, GitHub for public) hold implementation specs only — /to-issues-style slices bound to a repo's code. Mixed usage is the norm for code efforts: one Planka card is the state pointer, the repo issue chain is the spec; state is never duplicated. When a Planka effort accretes significant code, it is promoted: carve a repo, move specs there, the card remains the pointer.
Per-project routing is a config key, not a judgment call: tracker = … in the existing .cc-os/config. A new os-status check reads it deterministically — present means a session silently knows where tasks live; absent in a git project means a nudge to run the routing/migration skill once.
Skills for the lifecycle: capture, list, board ops, routing/migration; named agents for card triage and board audit; deterministic Ruby scripts over the installed planka-api gem binary for everything mechanical.
An autonomy convention (three values: hitl / semi / afk-ready) carried as a Planka label, issue-header field, and recurrence-manifest key, so a session reading a task knows whether to prepare-and-ask, run-then-stop-at-gates, or barrel through to Review.
Tuning by living with it: an os-adr-style WHEN→THEN injection note ships as a best educated guess and is measured by the existing biweekly orchestration IRL audit (new rubric category), not by a dedicated wording-eval grid.

User Stories

As a multi-project freelancer, I want one written rule for what goes to Planka vs a git tracker, so that I always know where to look for tasks without re-deciding per project.
As a session user, I want the session to know deterministically which tracker governs the current repo, so that captured tasks land in the right place without me routing them.
As a session user, I want a tracker key in .cc-os/config to be the single source of that routing, so that the answer is a file read, not an inference.
As a session user, I want an os-status check that stays silent (or prints one line) when the tracker key is present, so that configured projects cost me nothing at session start.
As a session user, I want that check to nudge me exactly once per day in an unconfigured git project, so that onboarding happens without nagging.
As a project owner, I want a routing skill that inspects what tracking already exists (Planka board, Forgejo/GitHub issues, in-repo issue files), proposes a destination, and writes the config key, so that onboarding a project is one conversation.
As a project owner, I want that skill to migrate existing open issues/cards to the chosen tracker mechanically with back-links, so that history isn't lost and nothing is tracked twice.
As a session user, I want work discovered mid-session captured as a Backlog card (not a TODO comment or a forgotten remark), so that the board reflects reality.
As a session user, I want a capture skill that resolves repo → board deterministically (board named after the repo/client dir; Dev vs Clients project from ~/dev/* vs ~/clients/*), so that cards never land on the wrong board.
As a session user, I want the capture path to create missing boards with the uniform lists and label set via a board-ensure script, so that a new project's first card doesn't require manual board setup.
As a board owner, I want the board-ensure script to fix Planka's single-owner visibility trap (null the owner-manager, add my user as project manager) on any project it creates, so that bot-created projects are never invisible to me.
As a board owner, I want archived boards handled by the rename convention (archived--<name>), with activation automatic and archiving only on my explicit go-ahead, so that board lifecycle is safe and reversible.
As a session user, I want a list skill that shows the cards relevant to my current repo/board on demand, so that I pull board state when I choose (pull beats push).
As a human operator, I want AI-created cards to always enter at Backlog, and AI-moved cards to stop at Review, so that Next-pulling and Done-acceptance remain mine alone.
As a human operator, I want hitl-labeled cards never picked up autonomously by AI, so that judgment-work waits for me.
As a session user, I want a three-value autonomy vocabulary (hitl / semi / afk-ready) as Planka labels, so that a card tells me how to work it before I start.
As a session user, I want semi-labeled work to mean "run mechanical parts, stop at named decision gates," so that semi-autonomous tasks have a defined stopping contract.
As an issue author, I want the same vocabulary usable in issue-header Type fields and the recurrence manifest's autonomy key, so that one convention spans all three tracking surfaces.
As a developer on a code effort, I want one Planka card as the state pointer linking to the repo's issue chain, so that the board answers "is this effort done" while issues carry the specs.
As a developer, I want a promotion rule — when a Planka effort accretes significant code, carve a repo and move specs there via /to-issues, keeping the card as pointer — so that specs live next to the code they specify.
As an operations owner, I want a general "operations" board for cross-project recurring/AI-checked cadence work, so that quality-of-life checks (orchestration audit, rotations, verifications) don't pollute project boards.
As an operations owner, I want recurring cards (e.g. the biweekly orchestration IRL audit) to accumulate progress history as comments, so that the board carries a human-readable history alongside machine ledgers.
As a card-triage requester, I want a named triage agent that assigns priority and autonomy labels to raw Backlog cards, so that capture stays cheap and triage stays batched.
As a board owner, I want a named board-audit agent that reports drift (stale Doing, WIP over cap, Waiting items unblocked, Review items aging), so that the process stays honest without me policing it.
As a session user, I want a SessionStart injection note with WHEN→THEN behavioral rules (capture, route, promote, column ownership, autonomy labels), so that sessions act on the convention without being told each time.
As a human operator, I want that note to carry rules only — never board state or briefs — so that notification policy v2 (pull beats push) holds.
As the convention's owner, I want session compliance measured by the existing biweekly IRL audit via a new capture/route/promote rubric category, so that tuning is driven by production evidence.
As the convention's owner, I want no dedicated wording-eval grid unless IRL audits show persistent misses, so that eval effort is spent only when the cheap loop fails.
As a /to-issues user, I want the skill's output routed by the tracker convention (Planka cards by default; repo issues only where the config key says so), so that slicing and routing don't fight.
As a multi-machine user, I want all plugin behavior to work from any machine with the gem binary installed and fail soft (silent no-op) where Planka is unreachable, so that offline sessions never break at session start.
As the plugin's maintainer, I want every deterministic behavior covered by model-free tests, so that regressions are caught without burning eval tokens.

Implementation Decisions

New global plugin os-backlog under the cc-os plugin family (ADR-023). Naming per the plugin/skill naming convention: verb-first skills invoked as /os-backlog:<verb>; no name: frontmatter; no commands/ dispatcher directories.
Boundary rule (the routing convention): Planka = task state, default for all work. Git issues = implementation specs only. Card-as-pointer + issue-chain-as-spec for code efforts; single owner of state per work item (the card). Promotion rule as stated in the Solution. This amends and formalizes the pilot plan's tracker-routing rule.
tracker key in .cc-os/config (the existing per-project config file os-status already reads). Value grammar: planka:<board> | forgejo:<owner>/<repo> | github:<owner>/<repo> | repo:<path> (in-repo markdown issues). Absence in a git project is the onboarding trigger.
New os-status check registered in the existing check registry: key present → ok/one-line note; absent in a git project → daily-snoozed warn pointing at the routing skill. Honors the existing snooze/suppress markers. os-status's invariants (always exit 0, state only in .cc-os/) apply unchanged.
Routing resolution is a pure function exposed as a CLI subcommand (Ruby, Sandi Metz style, mirroring the os-adr lib/ + CLI pattern): input = repo path + config + board inventory; output = one of use <board> / activate <archived board> / stop-and-discuss. No live API inside the resolver.
Deterministic scripts call the installed planka-api gem binary — no cross-repo source coupling (pilot-plan repo-separation decision). Board-ensure enforces uniform lists (Backlog → Next → Doing → Waiting → Review → Done) and the uniform label set (P0–P3 + autonomy labels), applies the verified Planka 2.1.1 API requirements (undocumented type fields on create; owner-manager visibility fix; label color whitelist), and implements the archive/activate rename convention.
Autonomy convention: the existing hitl / afk-ready labels are kept; semi is added as the third value. Same vocabulary in issue-header Type: fields and as an autonomy: key in the recurrence manifest (the manifest key is consumed by the planka gem's tick — passing it through is gem work, tracked as gem issue 13's release pass, out of this plugin's scope).
Column ownership is enforced in skill wording, not code: AI creates at Backlog, moves Doing → Review, never touches Next-pulling or Review → Done; hitl cards are never self-assigned.
Operations board: a general board (Dev project) for cross-project recurring/AI-checked work; recurring entries target it via the manifest's board field. Tick-fed population is blocked on gem issue 13 (offset expansion + versioning) — out of scope here; the board itself and manual cards are in scope.
Named agents: card-triage (labels/priorities raw Backlog cards) and board-audit (drift report). Both read-mostly; any writes land as comments or label changes, never column moves past Review.
SessionStart injection note modeled on os-adr's note: WHEN→THEN mechanical triggers for capture, routing, and promotion. Rules only; no board state (notification policy v2). Shipped as best educated guess; wording iterated only from IRL-audit evidence.
/to-issues integration: the routing skill/convention becomes the router for /to-issues output — Planka by default, repo issues where the config key says so.
Failure mode: every hook/script path fails soft when Planka or the gem binary is unavailable (silent ok at session start; explicit error only on user-invoked skills).

Testing Decisions

Good tests here assert external behavior at the seam, never implementation details: given a config/fixture state, the check emits ok/note/warn with the expected message; given inputs, the resolver prints the expected decision; given a stubbed client, the script issues the expected calls.
os-status check: tested in the existing model-free hook_test.py suite, same pattern as the other registry checks (env-var override for fixture paths; missing config silent outside git projects; snooze honored).
Routing resolver + deterministic scripts: pure Ruby unit tests with the gem's client layer stubbed/fixtured — prior art: the planka gem's VCR-independent recurrence unit tests and os-adr's lib/adr/ test suite. No live-API calls in CI/tests; live verification happens once, manually, per the pilot's verified-API notes.
Skill and injection wording: deliberately not unit- or grid-tested. Measured at the production seam by the biweekly orchestration IRL audit — the rubric gains a capture/route/promote category. A dedicated wording-eval harness is explicitly deferred unless audits show persistent misses.

Out of Scope

Recurrence offset expansion (+1d/+1w/+2w), the manifest autonomy key pass-through, and gem publish/versioning — planka gem issue 13.
The pull-based unified dashboard (own Planka card; explicitly held off).
Apprise/notification expansion (ADR-024 P2/P3 cards) — this plugin sends no notifications.
Property-management / business-dev boards (deferred by the pilot plan).
Bulk re-triage of the ~50 seeded cards and the Review → Done sweep (human gate).
Any Planka server/deploy changes (ovh-prod repo's concern).

Further Notes

Rollout mirrors the established pattern: build against cc-os first, onboard other projects one at a time via the routing skill.
The plugin depends on the gem binary; version pinning becomes meaningful once issue 13's versioning pass lands.
ADR-023 records the plugin-home decision; a follow-up ADR should record the tracker-routing convention once this PRD is accepted, since it amends the pilot plan's Forgejo rule.
The biweekly IRL audit's rubric change (new category) touches os-orchestration's rubric file — a deliberate cross-plugin edit consistent with the ecosystem framing in ADR-023.

# PRD: os-backlog plugin — the AI's process-management surface _Phase-1 PRD deferred by the backlog pilot plan (vault: `vault-backlog-pilot-plan`); plugin home decided in ADR-023. Drafted 2026-07-10._ ## Problem Statement Task and process state is now live in Planka (pilot gate passed 2026-07-09), but the AI has no formal surface for it. Sessions don't know where a project's tasks live (Planka board? Forgejo issues? in-repo markdown files?), don't reliably capture work discovered mid-session, and have no convention telling them how autonomously to act on a given task. The human ends up as the router: repeating "where do I look for tasks" decisions per project, manually shepherding cards, and never being sure the board reflects reality. Three trackers exist with no written boundary between them, and nothing deterministic tells a session which one is in effect for the repo it's sitting in. ## Solution A new global `os-backlog` plugin that makes tracker routing deterministic and task behavior conventional: - **One boundary rule, written down and injected:** Planka owns task *state* (the default for all work); git issues (Forgejo via `tea` for private repos, GitHub for public) hold implementation *specs* only — `/to-issues`-style slices bound to a repo's code. Mixed usage is the norm for code efforts: one Planka card is the state pointer, the repo issue chain is the spec; state is never duplicated. When a Planka effort accretes significant code, it is promoted: carve a repo, move specs there, the card remains the pointer. - **Per-project routing is a config key, not a judgment call:** `tracker = …` in the existing `.cc-os/config`. A new os-status check reads it deterministically — present means a session silently knows where tasks live; absent in a git project means a nudge to run the routing/migration skill once. - **Skills for the lifecycle:** capture, list, board ops, routing/migration; named agents for card triage and board audit; deterministic Ruby scripts over the installed `planka-api` gem binary for everything mechanical. - **An autonomy convention** (three values: `hitl` / `semi` / `afk-ready`) carried as a Planka label, issue-header field, and recurrence-manifest key, so a session reading a task knows whether to prepare-and-ask, run-then-stop-at-gates, or barrel through to Review. - **Tuning by living with it:** an os-adr-style WHEN→THEN injection note ships as a best educated guess and is measured by the existing biweekly orchestration IRL audit (new rubric category), not by a dedicated wording-eval grid. ## User Stories 1. As a multi-project freelancer, I want one written rule for what goes to Planka vs a git tracker, so that I always know where to look for tasks without re-deciding per project. 2. As a session user, I want the session to know deterministically which tracker governs the current repo, so that captured tasks land in the right place without me routing them. 3. As a session user, I want a `tracker` key in `.cc-os/config` to be the single source of that routing, so that the answer is a file read, not an inference. 4. As a session user, I want an os-status check that stays silent (or prints one line) when the tracker key is present, so that configured projects cost me nothing at session start. 5. As a session user, I want that check to nudge me exactly once per day in an unconfigured git project, so that onboarding happens without nagging. 6. As a project owner, I want a routing skill that inspects what tracking already exists (Planka board, Forgejo/GitHub issues, in-repo issue files), proposes a destination, and writes the config key, so that onboarding a project is one conversation. 7. As a project owner, I want that skill to migrate existing open issues/cards to the chosen tracker mechanically with back-links, so that history isn't lost and nothing is tracked twice. 8. As a session user, I want work discovered mid-session captured as a Backlog card (not a TODO comment or a forgotten remark), so that the board reflects reality. 9. As a session user, I want a capture skill that resolves repo → board deterministically (board named after the repo/client dir; Dev vs Clients project from `~/dev/*` vs `~/clients/*`), so that cards never land on the wrong board. 10. As a session user, I want the capture path to create missing boards with the uniform lists and label set via a board-ensure script, so that a new project's first card doesn't require manual board setup. 11. As a board owner, I want the board-ensure script to fix Planka's single-owner visibility trap (null the owner-manager, add my user as project manager) on any project it creates, so that bot-created projects are never invisible to me. 12. As a board owner, I want archived boards handled by the rename convention (`archived--<name>`), with activation automatic and archiving only on my explicit go-ahead, so that board lifecycle is safe and reversible. 13. As a session user, I want a list skill that shows the cards relevant to my current repo/board on demand, so that I pull board state when I choose (pull beats push). 14. As a human operator, I want AI-created cards to always enter at Backlog, and AI-moved cards to stop at Review, so that Next-pulling and Done-acceptance remain mine alone. 15. As a human operator, I want `hitl`-labeled cards never picked up autonomously by AI, so that judgment-work waits for me. 16. As a session user, I want a three-value autonomy vocabulary (`hitl` / `semi` / `afk-ready`) as Planka labels, so that a card tells me how to work it before I start. 17. As a session user, I want `semi`-labeled work to mean "run mechanical parts, stop at named decision gates," so that semi-autonomous tasks have a defined stopping contract. 18. As an issue author, I want the same vocabulary usable in issue-header Type fields and the recurrence manifest's `autonomy` key, so that one convention spans all three tracking surfaces. 19. As a developer on a code effort, I want one Planka card as the state pointer linking to the repo's issue chain, so that the board answers "is this effort done" while issues carry the specs. 20. As a developer, I want a promotion rule — when a Planka effort accretes significant code, carve a repo and move specs there via `/to-issues`, keeping the card as pointer — so that specs live next to the code they specify. 21. As an operations owner, I want a general "operations" board for cross-project recurring/AI-checked cadence work, so that quality-of-life checks (orchestration audit, rotations, verifications) don't pollute project boards. 22. As an operations owner, I want recurring cards (e.g. the biweekly orchestration IRL audit) to accumulate progress history as comments, so that the board carries a human-readable history alongside machine ledgers. 23. As a card-triage requester, I want a named triage agent that assigns priority and autonomy labels to raw Backlog cards, so that capture stays cheap and triage stays batched. 24. As a board owner, I want a named board-audit agent that reports drift (stale Doing, WIP over cap, Waiting items unblocked, Review items aging), so that the process stays honest without me policing it. 25. As a session user, I want a SessionStart injection note with WHEN→THEN behavioral rules (capture, route, promote, column ownership, autonomy labels), so that sessions act on the convention without being told each time. 26. As a human operator, I want that note to carry rules only — never board state or briefs — so that notification policy v2 (pull beats push) holds. 27. As the convention's owner, I want session compliance measured by the existing biweekly IRL audit via a new capture/route/promote rubric category, so that tuning is driven by production evidence. 28. As the convention's owner, I want no dedicated wording-eval grid unless IRL audits show persistent misses, so that eval effort is spent only when the cheap loop fails. 29. As a `/to-issues` user, I want the skill's output routed by the tracker convention (Planka cards by default; repo issues only where the config key says so), so that slicing and routing don't fight. 30. As a multi-machine user, I want all plugin behavior to work from any machine with the gem binary installed and fail soft (silent no-op) where Planka is unreachable, so that offline sessions never break at session start. 31. As the plugin's maintainer, I want every deterministic behavior covered by model-free tests, so that regressions are caught without burning eval tokens. ## Implementation Decisions - **New global plugin `os-backlog`** under the cc-os plugin family (ADR-023). Naming per the plugin/skill naming convention: verb-first skills invoked as `/os-backlog:<verb>`; no `name:` frontmatter; no `commands/` dispatcher directories. - **Boundary rule (the routing convention):** Planka = task state, default for all work. Git issues = implementation specs only. Card-as-pointer + issue-chain-as-spec for code efforts; single owner of state per work item (the card). Promotion rule as stated in the Solution. This amends and formalizes the pilot plan's tracker-routing rule. - **`tracker` key in `.cc-os/config`** (the existing per-project config file os-status already reads). Value grammar: `planka:<board>` | `forgejo:<owner>/<repo>` | `github:<owner>/<repo>` | `repo:<path>` (in-repo markdown issues). Absence in a git project is the onboarding trigger. - **New os-status check** registered in the existing check registry: key present → ok/one-line note; absent in a git project → daily-snoozed warn pointing at the routing skill. Honors the existing snooze/suppress markers. os-status's invariants (always exit 0, state only in `.cc-os/`) apply unchanged. - **Routing resolution is a pure function exposed as a CLI subcommand** (Ruby, Sandi Metz style, mirroring the os-adr `lib/` + CLI pattern): input = repo path + config + board inventory; output = one of `use <board>` / `activate <archived board>` / `stop-and-discuss`. No live API inside the resolver. - **Deterministic scripts call the installed `planka-api` gem binary** — no cross-repo source coupling (pilot-plan repo-separation decision). Board-ensure enforces uniform lists (`Backlog → Next → Doing → Waiting → Review → Done`) and the uniform label set (`P0–P3` + autonomy labels), applies the verified Planka 2.1.1 API requirements (undocumented `type` fields on create; owner-manager visibility fix; label color whitelist), and implements the archive/activate rename convention. - **Autonomy convention:** the existing `hitl` / `afk-ready` labels are kept; `semi` is added as the third value. Same vocabulary in issue-header `Type:` fields and as an `autonomy:` key in the recurrence manifest (the manifest key is consumed by the planka gem's tick — passing it through is gem work, tracked as gem issue 13's release pass, out of this plugin's scope). - **Column ownership is enforced in skill wording, not code:** AI creates at Backlog, moves Doing → Review, never touches Next-pulling or Review → Done; `hitl` cards are never self-assigned. - **Operations board:** a general board (Dev project) for cross-project recurring/AI-checked work; recurring entries target it via the manifest's `board` field. Tick-fed population is blocked on gem issue 13 (offset expansion + versioning) — out of scope here; the board itself and manual cards are in scope. - **Named agents:** `card-triage` (labels/priorities raw Backlog cards) and `board-audit` (drift report). Both read-mostly; any writes land as comments or label changes, never column moves past Review. - **SessionStart injection note** modeled on os-adr's note: WHEN→THEN mechanical triggers for capture, routing, and promotion. Rules only; no board state (notification policy v2). Shipped as best educated guess; wording iterated only from IRL-audit evidence. - **`/to-issues` integration:** the routing skill/convention becomes the router for `/to-issues` output — Planka by default, repo issues where the config key says so. - **Failure mode:** every hook/script path fails soft when Planka or the gem binary is unavailable (silent ok at session start; explicit error only on user-invoked skills). ## Testing Decisions - Good tests here assert **external behavior at the seam**, never implementation details: given a config/fixture state, the check emits ok/note/warn with the expected message; given inputs, the resolver prints the expected decision; given a stubbed client, the script issues the expected calls. - **os-status check:** tested in the existing model-free `hook_test.py` suite, same pattern as the other registry checks (env-var override for fixture paths; missing config silent outside git projects; snooze honored). - **Routing resolver + deterministic scripts:** pure Ruby unit tests with the gem's client layer stubbed/fixtured — prior art: the planka gem's VCR-independent recurrence unit tests and os-adr's `lib/adr/` test suite. No live-API calls in CI/tests; live verification happens once, manually, per the pilot's verified-API notes. - **Skill and injection wording:** deliberately not unit- or grid-tested. Measured at the production seam by the biweekly orchestration IRL audit — the rubric gains a capture/route/promote category. A dedicated wording-eval harness is explicitly deferred unless audits show persistent misses. ## Out of Scope - Recurrence offset expansion (`+1d/+1w/+2w`), the manifest `autonomy` key pass-through, and gem publish/versioning — planka gem issue 13. - The pull-based unified dashboard (own Planka card; explicitly held off). - Apprise/notification expansion (ADR-024 P2/P3 cards) — this plugin sends no notifications. - Property-management / business-dev boards (deferred by the pilot plan). - Bulk re-triage of the ~50 seeded cards and the Review → Done sweep (human gate). - Any Planka server/deploy changes (ovh-prod repo's concern). ## Further Notes - Rollout mirrors the established pattern: build against cc-os first, onboard other projects one at a time via the routing skill. - The plugin depends on the gem *binary*; version pinning becomes meaningful once issue 13's versioning pass lands. - ADR-023 records the plugin-home decision; a follow-up ADR should record the tracker-routing convention once this PRD is accepted, since it amends the pilot plan's Forgejo rule. - The biweekly IRL audit's rubric change (new category) touches `os-orchestration`'s rubric file — a deliberate cross-plugin edit consistent with the ecosystem framing in ADR-023.

jared added the

ready-for-agent

label 2026-07-10 17:10:52 +00:00

jared referenced this issue

2026-07-10 17:22:33 +00:00

os-backlog slice 1: plugin scaffold + board-ensure script #10

jared referenced this issue

2026-07-10 17:22:33 +00:00

os-backlog slice 2: tracker config key + os-status check #11

jared referenced this issue

2026-07-10 17:22:33 +00:00

os-backlog slice 3: routing resolver CLI #12

jared referenced this issue

2026-07-10 17:22:34 +00:00

os-backlog slice 4: capture + list skills #13

jared referenced this issue

2026-07-10 17:22:34 +00:00

os-backlog slice 5: routing/migration skill #14

jared referenced this issue

2026-07-10 17:22:35 +00:00

os-backlog slice 6: card-triage + board-audit named agents #15

jared referenced this issue

2026-07-10 17:22:35 +00:00

os-backlog slice 7: SessionStart injection note + /to-issues routing #16

jared referenced this issue

2026-07-10 17:22:36 +00:00

os-backlog slice 8: operations board + measurement wiring + routing ADR #17

jared referenced this issue from a commit

2026-07-10 20:54:27 +00:00

docs: record os-backlog AFK slices (refs #9, #10-#13, #15)

jared removed the

ready-for-agent

label 2026-07-12 22:25:52 +00:00

jared commented

2026-07-12 22:25:52 +00:00

Author

Owner

This was generated by AI during triage.

Removed ready-for-agent: this is the PRD/tracking issue, not a grabbable slice. Status: slices 1–6 (#10–#15) shipped and closed; remaining are #16 (unblocked) and #17 (blocked by #16). Close this once #17 lands.

> *This was generated by AI during triage.* Removed ready-for-agent: this is the PRD/tracking issue, not a grabbable slice. Status: slices 1–6 (#10–#15) shipped and closed; remaining are #16 (unblocked) and #17 (blocked by #16). Close this once #17 lands.

jared commented

2026-07-13 20:28:50 +00:00

Author

Owner

PRD scope delivered: all 31 user stories and every implementation/testing decision are built, tested (138 runs / 295 assertions / 0 failures), and live — capture/list/route skills, card-triage + board-audit agents, CLI-enforced column ownership (ADR-029), tracker key + os-status check, autonomy labels, session-start injection, /to-issues integration. Residuals tracked elsewhere: board-lookup name-collision bug (Backlog card), recurrence autonomy pass-through + tick-fed operations board (blocked on planka gem issue #13), onboard-a-second-project rollout (new Backlog card). Closing as delivered.

jared closed this issue

2026-07-13 20:28:50 +00:00

jared referenced this issue from a commit

2026-07-15 19:10:57 +00:00

os-doc-hygiene: lifecycle-aware hygiene implementation + calibration pass #1 (map #31)

jared referenced this issue

2026-07-16 18:44:11 +00:00

os-backlog rollout: onboard a second project via /os-backlog:route #66