ccFamily
[ MENU ]
SECT. 01 // PLUGIN · ADR CLI · PLANNED · LICENSE TBD

⚠ DESIGN PREVIEW · NOT YET BUILT · NO PUBLIC RELEASE

ccReason/
ccRecall's
ADR plugin

// READ(ccrecall.memories + knowledge_map) → REASON → ADR.md

An independent npm package that reads ccRecall's shared schema to derive Architecture Decision Records. Turns the decision context you've discussed with Claude into committable ADR markdown. Design is locked in; implementation is still pending.

// No release date — design first; implementation kicks off after Phase 02 ccRewind converges.

SECT. 02 // DESIGN RATIONALE

Why a plugin, not a subcommand, not a peer?

ccReason's core action is reading ccRecall's memories and knowledge_map tables to derive ADRs — its read/write path depends on ccRecall's SQLite schema. Three architectural options sat on the table:

REJECTED · OPTION A

Standalone peer

Making it a third peer would mean reinventing the storage layer — its own SQLite schema, its own indexer, its own lifecycle. Wasteful, plus there's a double-write risk (the memory ADR reasoning needs may not have synced yet).

// duplicate storage layer

REJECTED · OPTION B

ccrecall subcommand

Making it ccrecall reason adr would pollute ccRecall's codebase — ADR reasoning is a separate concern; folding it into the memory layer makes both more complicated. Lifecycles would also tightly couple.

// codebase pollution

▲ ADOPTED · OPTION C

plugin (shared schema)

An independent @tznthou/ccreason npm package that reads ccRecall's SQLite schema. Independent lifecycle, independent codebase, shared data layer. Best of both worlds.

// independent npm + shared schema

// Still a CLI, still ADR markdown, still Apache-friendly. Complements the V2 ADR CLI direction; doesn't overturn it.

SECT. 03 // EXECUTION FLOW

Read ccRecall's memories + knowledge_map, emit ADRs.

SHARED SCHEMA · ccRecall TABLES

→ memories // Structured memory (decisions, observations, learnings)

→ knowledge_map // Concept graph (topic → related_memories)

→ See full ccFamily schema in [/architecture/]

→ 01 QUERY

Query Relevant Memories

Anchor on the ADR topic. Pull related memories from ccRecall's knowledge_map. FTS5 + graph traversal run in parallel.

→ 02 SYNTHESIZE

Synthesize

Organize the scattered decisions / observations / learnings into a Context / Decision / Consequences structure (standard ADR format).

→ 03 EMIT

Emit ADR.md

Write markdown to docs/adr/NNNN-*.md, committable to git. Standard ADR format (Status / Context / Decision / Consequences).

SECT. 04 // CLI PREVIEW · DESIGN MOCKUP

Expected CLI (mock — not yet built)

The commands and output below are a design preview, not yet runnable. The actual interface may shift during implementation.

⚠ MOCK · DESIGN PREVIEW
$ ccreason adr "why did we switch to NATS"

# Reading ccRecall: 12 relevant memories
# knowledge_map → topic="messaging" → 8 related entries

→ Synthesizing...

✓ ADR-042 written: docs/adr/0042-switch-to-nats.md

  Status: Accepted
  Context: 5 weeks of latency issues with RabbitMQ persistent queues...
  Decision: Migrate to NATS JetStream for at-least-once delivery...
  Consequences: +3 services impacted, -40% p99 latency observed...

# Sources: 12 memories from ccRecall (2026-03-15 to 2026-04-22)
# Confidence: 0.78 (high · 8/12 sources direct, 4/12 inferred)

// ccReason doesn't make decisions for you — it only synthesizes what you and Claude have already discussed. Below-threshold confidence aborts the run and lists the missing context.

SECT. 05 · FINAL

PHASE 03
Ready to start, but not yet written

PROJECT TIMELINE

PHASE 01 · LIVE — ccRecall v0.5.6 (memory layer)

PHASE 02 · LIVE — ccRewind v1.19.2 (archaeology app)

PHASE 03 · PLANNED — ccReason (ADR plugin · you are here)

// No promised release date — design first; implementation kicks off after the ccRewind roadmap converges.

Want to join the ADR design discussion? Or track implementation progress? Two entry points:

// CCRECALL REPO // CCREASON REPO (TBD)