# NCS — NAMING & CONTRACT SPEC
version: v1.0
status: ACTIVE
parent: master_architecture_index.md
phase: 02
phase_name: Architecture & Engineering Canon
document_role: naming_and_contract_standard_for_phase_02

---

## 1. OBJECTIVE

Define canonical naming rules for Devon architecture, documentation, runtime artifacts, panel data, phases, contracts and operational identifiers.

This document standardizes:
- file names
- document siglas
- canonical IDs
- phase labels
- card IDs
- section IDs
- path conventions
- contract naming patterns

---

## 2. NAMING PRINCIPLE

Every canonical artifact must be:
- explicit
- stable
- singular in responsibility
- machine-readable
- human-readable
- traceable to phase and role

No decorative naming allowed.
No vague naming allowed.
No duplicate purpose naming allowed.

---

## 3. FILE NAMING RULES

### 3.1 Canonical Data Files
Canonical structured files must use:

`snake_case.json`

Examples:
- project_scope_canonical.json
- deployment_order_canonical.json
- panel_canonical_tree.json
- server_registry_canonical.json

### 3.2 Canonical Markdown Files
Canonical textual governance/spec files must use:

`lowercase_sigla.md`

Examples:
- cgs.md
- ncs.md
- acs.md
- cas.md
- ris.md

### 3.3 Forbidden Patterns
Forbidden:
- spaces in file names
- camelCase file names
- mixed separators
- decorative suffixes
- vague names like:
  - final_doc.md
  - new_version.md
  - temp_file.md
  - architecture_notes.md

---

## 4. DOCUMENT SIGLA RULES

Every canonical spec must have:
- a unique sigla
- one sigla = one responsibility
- no sigla reuse

Examples:
- CGS = Canonical Governance Spec
- NCS = Naming & Contract Spec
- ACS = Artifact Canon Spec
- CAS = Cognitive Architecture Spec
- RIS = Role Isolation Spec
- STS = State & Transition Spec
- OFMS = Operational Flow Master Spec
- CDMS = Containerization & Deployment Master Spec
- CSS = Contract & Schema Spec
- BRPS = Build, Release & Promotion Spec

---

## 5. PATH RULES

### 5.1 Canonical Root
Canonical architecture reference root:

`/home/yeff/public_html/devon/panel/data/`

### 5.2 Master Reference
Primary consultation file:

`/home/yeff/public_html/devon/panel/data/master_architecture_index.md`

### 5.3 Rule
Canonical docs that govern panel, architecture or execution must live under:
- panel/data

Unless a higher canon explicitly defines another root.

---

## 6. PHASE NAMING RULES

Official phase names:

- Phase 01 — Overview & Scope
- Phase 02 — Architecture & Engineering Canon
- Phase 03 — Foundations Security
- Phase 04 — Performance, Observability & Quality
- Phase 05 — Architecture
- Phase 06 — Contracts
- Phase 07 — Runtime & Infrastructure
- Phase 08 — Memory & Learning
- Phase 09 — Operational Flows

### 6.1 Phase ID Format
Use:
- `phase: 02`
- `phase_name: Architecture & Engineering Canon`

### 6.2 Forbidden
Do not use:
- informal aliases as authority
- multiple names for same phase
- reordered numbering without canon update

---

## 7. DOCUMENT HEADER CONTRACT

Every canonical md spec must declare:

- title
- version
- status
- parent
- phase
- phase_name
- document_role

Example:

```text
# CGS — CANONICAL GOVERNANCE SPEC
version: v1.0
status: ACTIVE
parent: master_architecture_index.md
phase: 02
phase_name: Architecture & Engineering Canon
document_role: governance_root_for_phase_02