coulomb-social/docs/capability/vocabulary.md
tegwick bc78cd27fc Adopt stage-1 capability cut and product capability model
Persist capability/feature vocabulary, v0 model, and founder stage-1 must set
(onboarding, spaces/pages with Title/Abstract/Visual, page copy and transfer).
Mark CSOC-WP-0001-T03 done; add CSOC-WP-0006 for implementation.
2026-08-12 13:09:09 +02:00

73 lines
2.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Capability / feature vocabulary (coulomb-social)
Status: **adopted for product work** (2026-08-12)
Promote to fleet canon after one full cutover cycle.
Cites: orthogonal architecture Capability (C1C3, `realizes`); reuse-surface
for *cross-product* reuse only — not product feature flags.
## The coin
| Side | Name | Question |
|------|------|----------|
| **Utility** | **Capability** | What can a person *do* or *get*? Stable job-to-be-done. |
| **Implementation** | **Feature** | Which concrete product slice delivers (part of) that utility? |
Capabilities change slowly. Features appear, split, toggle, and retire under them.
## Hierarchy (depth capped)
```text
Capability
└── Feature+ (implementation slices)
└── Realization (code, config, deploy) — optional detail
└── Toggle? (runtime/config switch on a feature or stage)
```
Rules:
1. **Capabilities: few.** Target ~1030 for all of coulomb.social, not hundreds.
2. **No unlimited trees.** At most capability → optional sub-capability → feature.
3. **One feature, one primary capability.** Cross-links allowed as `supports`, not multi-parent ownership.
4. **Toggles attach to features (or release stages), never to capabilities.**
“Turn off identity” is a product decision, not a flag.
5. **Feature cut = prioritize capabilities**, then name which features are enough to call a capability *realized for that stage*.
6. **Partial rebuild is valid.** Stage N can retire Bubble as *productive* home while Bubble remains *reference-only* for later capabilities.
## Status labels
### Capability priority (cut / roadmap)
| Label | Meaning |
|-------|---------|
| `must_stage_1` | Required before user transfer + Bubble productive retirement |
| `later` | Rebuild after stage 1; not a transfer blocker |
| `out` | Explicitly not rebuilding (or only if strategy changes) |
| `platform` | Delivered by platform dependency (NetKingdom, Forgejo, …) |
### Feature implementation status
| Label | Meaning |
|-------|---------|
| `shipped` | On app.coulomb.social (or ready to enable) |
| `partial` | Exists but missing stage-1 acceptance bits |
| `todo` | Not built; required for its capability stage |
| `later` | Intentionally after stage 1 |
| `blocked` | Waiting on external dependency |
## What not to conflate
| Concept | Home |
|---------|------|
| Product capability (user utility) | This model |
| Fleet reusable capability | reuse-surface registry |
| Platform service (OIDC, Forgejo, apps-pg) | Platform deps; product *depends_on* |
| Feature toggle | Env/settings/flag on a **feature** |
| Workplan task | Execution unit; may implement many features |
## Naming
- Capabilities: `cap.<kebab>` — noun phrase of utility
e.g. `cap.space-content`
- Features: `feat.<kebab>` — verb/noun of implementation
e.g. `feat.space-md-render`
- Prefer stable ids; titles may change.