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.
73 lines
2.9 KiB
Markdown
73 lines
2.9 KiB
Markdown
# 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 (C1–C3, `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 ~10–30 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.
|