ubiquitous-language

# Ubiquitous language

Five different axes get called "version," "stage," or "status" across this
portfolio. They are independent — a thing can be V1, in the `dev` tier, on
Phase 0 R6, and still only "drafted." Naming the axis explicitly prevents
the recurring confusion this skill exists to fix.

## The five axes

| Axis | What it answers | Values | Scope |
|---|---|---|---|
| **Version** | Which build? | semver tag (`v1.4.3-telemetry.1`), package/image tag | One repo/artifact. A multi-repo delivery has one version *per repo* — they are not synonyms. (`xu4-support v0.1.2` and `xu4 engine v1.4.3-telemetry.1` are two different numbers for one delivery, not a mismatch to reconcile.) |
| **Stage / Tier** | Where is it running? | `dev` (safe QA/rapid-test tier — not "staging", see [[feedback_dev_means_staging_tier]]) → `production` | One deployment target. Orthogonal to version and delivery phase. |
| **Delivery Phase** | How mature is the product? | V0 (inventory state — working/partial/stale code, no release claim) → V1 (smallest coherent, released outcome) | Per the `v1-delivery-shaping` skill. Something can be V0 code already live in `production`, or V1-defined work still sitting in `dev`. |
| **MFD Phase** | Is this approved to build? | Phase 0 (scoping/approval gate) → approved → implementing. R1, R2, ... R9 are requirement checkpoints *inside one Phase 0 packet* | Per the `mapped-frontier-development` skill. R-numbers reset per packet/issue — R6 on one issue has no relationship to R6 on another. |
| **Task hierarchy** | What's the unit of work and how far along is it? | Epic → Issue → Sub-issue → PR | GitHub-native. See below for the states between "opened" and "live." |

Anything else that looks like a version/phase marker but isn't one of the
above — epic-local step letters (`S2`, `S4`...), a retirement "wave" number,
a sprint name — is **local to that one epic or program**. Don't assume it
maps onto another project's numbering, and don't reuse it as if it were a
portfolio-wide standard.

## Retire "shipped"

"Shipped" gets used for at least four different real states and causes real
confusion when read back later (e.g. a PR marked "shipped" that turns out to
still be a draft with unwired config). Use the precise word instead:

1. **drafted** — code pushed, PR open as draft, not yet reviewed.
2. **ready for review** — PR undrafted, review requested.
3. **merged** — landed on the integration branch (`dev` in this portfolio's
   convention — see the global `main` triggers real deployments rule).
4. **deployed** — running in a named tier, not yet confirmed working.
5. **live** — independently verified reachable/working in that tier (a real
   response checked, not just "the deploy step finished").

## Status-report template

When reporting or recording project state (memory, issue comment, status
update), state the axes that actually apply instead of one ambiguous word:

> `<project>`: version `<tag>` (repo: `<name>`), tier: `<dev|production>`,
> delivery phase: `<V0|V1>`, task state: `<drafted|ready for review|merged|
> deployed|live>`.

Omit an axis only when it's genuinely not applicable (e.g. a docs-only PR has
no version/tier). Don't collapse multiple axes into one word like "done" or
"shipped."

## Related skills

- `mapped-frontier-development` — owns the MFD Phase / R-number lifecycle in
  full; this glossary just places it relative to the other axes.
- `v1-delivery-shaping` — owns the V0/V1 delivery-phase definition in full;
  same relationship.
- `memory-audit` — periodically checks whether project memories are using
  these terms consistently, among other hygiene checks.