coulomb/markitect-main
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
markitect-main/history/260720-issue-facade-capability-extraction-paused
History
Exact
tegwick b8cd584c72
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 3s
Details
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>
2026-07-20 23:34:03 +02:00
..
README.md Archive stale TODO.md entry: capability-capability extraction (paused) 2026-07-20 23:34:03 +02:00

README.md

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