SDD system survey — 12 systems evaluated as sideshow pack candidates

[arcaven]

Context

kos session-014 surveyed 12 software-defined development (SDD) systems to evaluate their artifact models, filesystem fingerprints, storage mechanisms, and version detection — all toward determining which systems sideshow could support as managed content packs.

Ref: kos finding-042

Summary Table

System	Fingerprint	Storage	Stars / Maturity	Pack Priority
speckit	.specify/	Files (markdown)	77k, github/spec-kit	High
bmad	_bmad/	Files + CSV manifests	41k, already supported	N/A (current)
chainlink	.chainlink/	SQLite (issues.db)	~1k, dollspace-gay/chainlink	High
beads	.beads/	Dolt (versioned SQL)	20k, gastownhall/beads	High
multiclaude	.multiclaude/	JSON state	~5k, dlorenc/multiclaude	Medium
OpenClaudia	.openclaudia/	YAML + JSON	~2k, dollspace-gay/OpenClaudia	Medium
gastown	.gastown/	TOML + SQLite + JSONL	~8k, gastownhall/gastown	Low (uses beads)
pennyfarthing	.pennyfarthing/	YAML + MD	Legacy, predecessor to aclaude	Low (archived)
spectacle	spectacle.yaml	YAML + MD	ArcavenAE/spectacle	High (ecosystem)
kos	_kos/	YAML over git	ArcavenAE/kos	Medium (ecosystem)
vibecoding patterns	varies	Files	Emerging, no standard	Watch
cursor rules	.cursor/	Files	Widespread but proprietary	Watch

Key Findings

Fingerprint detection is reliable across systems

Every surveyed system creates a unique directory or manifest file at the project root. This makes detection straightforward: check for the fingerprint directory/file, then inspect version markers within it.

Three storage tiers

1. Files only (speckit, bmad, spectacle, pennyfarthing, kos) — sideshow can manage these directly via copy/symlink
2. Database-backed (chainlink/SQLite, beads/Dolt, gastown/SQLite+TOML) — sideshow manages configuration and rules, not the database itself
3. JSON/YAML state (multiclaude, OpenClaudia) — hybrid; sideshow manages templates and rules, runtime state is tool-managed

Bridge profile concept: kos-bridge.yaml

Each sideshow pack could ship a kos-bridge.yaml describing its artifacts for kos seed scanning:

• Fingerprints — how to detect the system in a project
• Artifact map — what files mean, what kos node types they map to
• Version detection — which file + field contains the version
• Version ranges — different layouts for different versions
• References — repo URL, docs, changelog

kos seed scan would load these profiles from sideshow's install path, enabling automatic graph population from any supported system's artifacts. The format should be designed after sideshow's pack.yaml format stabilizes.

Individual Issues

High-priority candidates have individual issues filed:

• spectacle (ArcavenAE ecosystem, natural second pack)
• speckit (77k stars, well-structured artifacts)
• chainlink (hooks and rules installation, VSDD methodology)
• beads (configuration management, AGENTS.md generation)
• Bridge profile format (kos-bridge.yaml)

What This Enables

Once sideshow supports multiple packs, it becomes the single entry point for AI CLI tool configuration across systems. A developer runs sideshow install speckit and gets the .claude/commands/, rules, and templates — same workflow as sideshow install bmad today. kos can then scan any sideshow-managed project and seed its graph from the bridge profiles.