Archive stale TODO.md entry: capability-capability extraction (paused)
Housekeeping triggered by the Forgejo daily-todo-md-stale-review flag (the-custodian issue #5, 12 days stale). Reviewed: the plan was written 2025-12-17 and its dependency (issue-facade) was detached the same day (capabilities/DETACHED-issue-facade.yaml) and never re-integrated since -- only a repo-wide rename has touched it in 7 months. No workplan, roadmap topic, or other repo picked this up. Archived per this repo's own history/yymmdd-topic/ convention rather than promoted to a workplan nobody asked for; TODO.md reset to clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
e9daaba50c
commit
b8cd584c72
2 changed files with 97 additions and 56 deletions
62
TODO.md
62
TODO.md
|
|
@ -14,59 +14,9 @@ See roadmap/YYMMDD-ROADMAPTOPIC/ directories for planning information like conce
|
||||||
|
|
||||||
This section is for tasks currently being discussed with or worked on by the coding assistant. These are the ephemeral, flow-of-thought tasks.
|
This section is for tasks currently being discussed with or worked on by the coding assistant. These are the ephemeral, flow-of-thought tasks.
|
||||||
|
|
||||||
### Extract Capability-Capability from Issue-Facade (Paused)
|
*(clean — 2026-07-20. Prior entry, "Extract Capability-Capability from
|
||||||
|
Issue-Facade," archived to
|
||||||
**Context:** Issue-facade currently provides two capabilities:
|
`history/260720-issue-facade-capability-extraction-paused/` after 7 months
|
||||||
1. **issue-tracking** (explicit in CAPABILITY-issue-tracking.yaml) - Issue management across platforms
|
with no forward motion and its dependency (`issue-facade`) detached the
|
||||||
2. **capability-capability** (implicit) - Patterns and tools for creating/managing capabilities
|
same day it was written; see that directory's README for the full
|
||||||
|
rationale.)*
|
||||||
The **capability-capability** includes:
|
|
||||||
- Feedback pattern (feedback/ directory, .capability/feedback CLI tool, documentation)
|
|
||||||
- Detachment facility (.capability/detach script for clean capability removal)
|
|
||||||
- Integration pattern (.capability/integrate.sh for project integration)
|
|
||||||
- CAPABILITY-*.yaml specification format
|
|
||||||
- ReusableCapabilitiesArchitecture.md (complete specification)
|
|
||||||
- Directory conventions (_family/implementation, visible/hidden patterns)
|
|
||||||
|
|
||||||
**Goal:** Extract capability-capability to separate `reusable-capability` repository so it can be used by any capability in the markitect ecosystem.
|
|
||||||
|
|
||||||
**Approach:** Step-by-step extraction, starting with specification.
|
|
||||||
|
|
||||||
#### Phase 1: Specification & Planning (Current)
|
|
||||||
|
|
||||||
- [ ] Create CAPABILITY-capability.yaml in issue-facade to explicitly declare the implicit capability
|
|
||||||
- [ ] Define what belongs to capability-capability family vs issue-tracking family
|
|
||||||
- [ ] Document the capability-capability API surface (what tools/patterns it provides)
|
|
||||||
- [ ] Identify all files/directories to extract
|
|
||||||
- [ ] Plan extraction strategy (copy vs move, how to maintain during transition)
|
|
||||||
|
|
||||||
#### Phase 2: Repository Creation
|
|
||||||
|
|
||||||
- [ ] Create reusable-capability repository structure
|
|
||||||
- [ ] Extract ReusableCapabilitiesArchitecture.md to new repo
|
|
||||||
- [ ] Extract feedback pattern (directory structure, CLI tool, README)
|
|
||||||
- [ ] Extract detachment facility (.capability/detach)
|
|
||||||
- [ ] Extract integration scripts (.capability/integrate.sh, integration-checklist.md)
|
|
||||||
- [ ] Create CAPABILITY-capability.yaml in new repo (canonical version)
|
|
||||||
- [ ] Add README.md for reusable-capability repo
|
|
||||||
|
|
||||||
#### Phase 3: Integration & Testing
|
|
||||||
|
|
||||||
- [ ] Update issue-facade to depend on reusable-capability (as integrated capability)
|
|
||||||
- [ ] Integrate reusable-capability into issue-facade using _capability/reusable-capability pattern
|
|
||||||
- [ ] Test that issue-facade still works with extracted capability
|
|
||||||
- [ ] Update issue-facade documentation to reference both capabilities it provides/uses
|
|
||||||
- [ ] Verify feedback system still works
|
|
||||||
- [ ] Verify detachment still works
|
|
||||||
|
|
||||||
#### Phase 4: Dogfooding & Validation
|
|
||||||
|
|
||||||
- [ ] Choose another markitect capability for dogfooding
|
|
||||||
- [ ] Integrate reusable-capability into that capability
|
|
||||||
- [ ] Add feedback system to new capability
|
|
||||||
- [ ] Add detachment facility to new capability
|
|
||||||
- [ ] Document learnings and refine reusable-capability based on real-world usage
|
|
||||||
- [ ] Update ReusableCapabilitiesArchitecture.md with insights
|
|
||||||
|
|
||||||
**Current Step:** Phase 1, Task 1 - Create CAPABILITY-capability.yaml
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,91 @@
|
||||||
|
# Extract Capability-Capability from Issue-Facade — archived, paused
|
||||||
|
|
||||||
|
Archived 2026-07-20 during Forgejo-issue housekeeping (5 open issues
|
||||||
|
reviewed, 12 days old; two were the automated `daily-todo-md-stale-review`
|
||||||
|
staleness flag — see `the-custodian/activity-definitions/
|
||||||
|
daily-todo-md-stale-review.md`). This is the content that was sitting in
|
||||||
|
`TODO.md`'s "Active Vibe-Coding State" section, unchanged since it was
|
||||||
|
written.
|
||||||
|
|
||||||
|
## Why archived, not promoted to a workplan
|
||||||
|
|
||||||
|
- **Origin:** `TODO.md` entry added 2025-12-17
|
||||||
|
(`916c09a2 docs: add capability-capability extraction plan to TODO.md`).
|
||||||
|
- **Same-day detachment:** `issue-facade` — the capability this plan
|
||||||
|
extracts *from* — was detached the same day
|
||||||
|
(`capabilities/DETACHED-issue-facade.yaml`, timestamp
|
||||||
|
`2025-12-17T21:23:14Z`) and has not been re-integrated since (only touch
|
||||||
|
since: an April 2026 repo-wide rename commit, not a re-integration).
|
||||||
|
- **No forward motion in 7 months.** The plan itself is explicitly marked
|
||||||
|
"(Paused)" in its own heading, at Phase 1 Task 1 of 4 phases.
|
||||||
|
- No other repo, workplan, or roadmap topic references
|
||||||
|
`capability-capability` or `reusable-capability` — this was never picked
|
||||||
|
up elsewhere.
|
||||||
|
|
||||||
|
Net: the dependency this plan builds on is inactive and nothing since
|
||||||
|
December suggests continued interest. Per ADR-001 (repo-primary work
|
||||||
|
items) and this repo's own `history/` convention, stale planning content
|
||||||
|
without live signal is archived here rather than carried forward
|
||||||
|
speculatively or promoted into a workplan nobody asked for.
|
||||||
|
|
||||||
|
**If this work becomes relevant again:** re-integrate `issue-facade`
|
||||||
|
first, then open a fresh `workplans/MARKITECT-WP-NNNN-*.md` per ADR-001 —
|
||||||
|
don't resurrect this file as a plan; treat it as prior-art reference only.
|
||||||
|
|
||||||
|
## Original content (verbatim, from TODO.md)
|
||||||
|
|
||||||
|
### Extract Capability-Capability from Issue-Facade (Paused)
|
||||||
|
|
||||||
|
**Context:** Issue-facade currently provides two capabilities:
|
||||||
|
1. **issue-tracking** (explicit in CAPABILITY-issue-tracking.yaml) - Issue management across platforms
|
||||||
|
2. **capability-capability** (implicit) - Patterns and tools for creating/managing capabilities
|
||||||
|
|
||||||
|
The **capability-capability** includes:
|
||||||
|
- Feedback pattern (feedback/ directory, .capability/feedback CLI tool, documentation)
|
||||||
|
- Detachment facility (.capability/detach script for clean capability removal)
|
||||||
|
- Integration pattern (.capability/integrate.sh for project integration)
|
||||||
|
- CAPABILITY-*.yaml specification format
|
||||||
|
- ReusableCapabilitiesArchitecture.md (complete specification)
|
||||||
|
- Directory conventions (_family/implementation, visible/hidden patterns)
|
||||||
|
|
||||||
|
**Goal:** Extract capability-capability to separate `reusable-capability` repository so it can be used by any capability in the markitect ecosystem.
|
||||||
|
|
||||||
|
**Approach:** Step-by-step extraction, starting with specification.
|
||||||
|
|
||||||
|
#### Phase 1: Specification & Planning (Current)
|
||||||
|
|
||||||
|
- [ ] Create CAPABILITY-capability.yaml in issue-facade to explicitly declare the implicit capability
|
||||||
|
- [ ] Define what belongs to capability-capability family vs issue-tracking family
|
||||||
|
- [ ] Document the capability-capability API surface (what tools/patterns it provides)
|
||||||
|
- [ ] Identify all files/directories to extract
|
||||||
|
- [ ] Plan extraction strategy (copy vs move, how to maintain during transition)
|
||||||
|
|
||||||
|
#### Phase 2: Repository Creation
|
||||||
|
|
||||||
|
- [ ] Create reusable-capability repository structure
|
||||||
|
- [ ] Extract ReusableCapabilitiesArchitecture.md to new repo
|
||||||
|
- [ ] Extract feedback pattern (directory structure, CLI tool, README)
|
||||||
|
- [ ] Extract detachment facility (.capability/detach)
|
||||||
|
- [ ] Extract integration scripts (.capability/integrate.sh, integration-checklist.md)
|
||||||
|
- [ ] Create CAPABILITY-capability.yaml in new repo (canonical version)
|
||||||
|
- [ ] Add README.md for reusable-capability repo
|
||||||
|
|
||||||
|
#### Phase 3: Integration & Testing
|
||||||
|
|
||||||
|
- [ ] Update issue-facade to depend on reusable-capability (as integrated capability)
|
||||||
|
- [ ] Integrate reusable-capability into issue-facade using _capability/reusable-capability pattern
|
||||||
|
- [ ] Test that issue-facade still works with extracted capability
|
||||||
|
- [ ] Update issue-facade documentation to reference both capabilities it provides/uses
|
||||||
|
- [ ] Verify feedback system still works
|
||||||
|
- [ ] Verify detachment still works
|
||||||
|
|
||||||
|
#### Phase 4: Dogfooding & Validation
|
||||||
|
|
||||||
|
- [ ] Choose another markitect capability for dogfooding
|
||||||
|
- [ ] Integrate reusable-capability into that capability
|
||||||
|
- [ ] Add feedback system to new capability
|
||||||
|
- [ ] Add detachment facility to new capability
|
||||||
|
- [ ] Document learnings and refine reusable-capability based on real-world usage
|
||||||
|
- [ ] Update ReusableCapabilitiesArchitecture.md with insights
|
||||||
|
|
||||||
|
**Current Step:** Phase 1, Task 1 - Create CAPABILITY-capability.yaml
|
||||||
Loading…
Add table
Add a link
Reference in a new issue