Add enterprise appliance experience Phase 1 foundation

.specify/memory/constitution.md

@@ -0,0 +1,107 @@
+<!--
+Sync Impact Report
+- Version change: template -> 1.0.0
+- Added principles:
+  - I. Enterprise Appliance Experience
+  - II. Safe, Recoverable Lifecycle
+  - III. Secure and Auditable by Default
+  - IV. Entitlement and Packaging Integrity
+  - V. Evidence-Based Quality
+- Added sections: Product and Operational Constraints; Delivery Quality Gates
+- Templates updated:
+  - ✅ .specify/templates/plan-template.md
+  - ✅ .specify/templates/spec-template.md
+  - ✅ .specify/templates/tasks-template.md
+- Follow-up TODOs: none
+-->
+# Nexus One AI Constitution
+
+## Core Principles
+
+### I. Enterprise Appliance Experience
+Every customer-facing journey MUST feel complete, coherent, and intentional across first boot,
+setup, login, administration, daily use, maintenance, and recovery. Screens MUST use consistent
+Nexus One AI naming, navigation, interaction patterns, and plain-language status messages. A
+customer MUST never encounter placeholder content, unexplained internal codes, dead controls, or
+demo-only behaviour in a release. Errors MUST state what happened, the customer impact, and a safe
+next action. Rationale: customers judge an appliance as one product, not as a collection of tools.
+
+### II. Safe, Recoverable Lifecycle
+Installation, configuration, upgrade, backup, restore, and removal paths MUST be designed as
+recoverable lifecycle operations. Changes MUST preserve supported existing installations and data,
+or include an explicit migration and rollback path. Destructive operations MUST require clear
+confirmation and MUST identify their scope. Interrupted operations MUST either resume safely or
+provide documented recovery steps. Rationale: an enterprise appliance remains trustworthy when
+normal operations fail, not only when the happy path succeeds.
+
+### III. Secure and Auditable by Default
+Secure defaults MUST apply without requiring customer expertise. Secrets, license material,
+credentials, and private customer data MUST never appear in source control, browser-visible logs,
+or routine diagnostics. Authentication and authorization MUST be enforced server-side. Privileged,
+security-sensitive, licensing, configuration, and lifecycle actions MUST produce useful audit
+records without leaking secrets. Security weakening for convenience requires explicit approval,
+documented risk, bounded scope, and a removal plan. Rationale: on-premises operation increases the
+need for predictable controls and supportable evidence.
+
+### IV. Entitlement and Packaging Integrity
+Commercial product labels and internal compatibility identifiers MUST remain deliberately mapped.
+Nexus One AI Workstation MUST remain structurally separate from the Server tier ladder, and the
+existing `starter`, `basic`, `pro`, and `max` identifiers MUST remain compatible unless an approved
+migration covers every consumer. Portal, backend, license logic, Ansible roles, installer, packaged
+payload, documentation, and ISO delivery MUST agree on capabilities and naming. A delivery artifact
+MUST NOT be called current until its packaged source and build provenance are verified. Rationale:
+entitlement drift creates customer-visible failures that are difficult to repair in the field.
+
+### V. Evidence-Based Quality
+No customer-facing feature is complete based only on code review or visual inspection. Each feature
+MUST define measurable acceptance criteria and MUST verify its primary journey, failure states,
+permissions, entitlement boundaries, and operational impact at the lowest sufficient test level.
+Changes spanning multiple surfaces MUST include end-to-end validation across those surfaces. Release
+claims MUST distinguish static checks, local tests, deployment tests, and live appliance validation.
+Known gaps MUST be documented rather than hidden. Rationale: enterprise quality is demonstrated by
+repeatable evidence.
+
+## Product and Operational Constraints
+
+- Branding MUST use **Nexus One AI** with **Powered by Cezen** where company attribution is shown.
+- Workstation and Server S/M/L/Max capability differences MUST be explicit and testable.
+- Customer-visible values MUST come from real configuration or clearly labelled example data; they
+  MUST NOT be fabricated as production state.
+- The platform MUST remain operable in customer-controlled and restricted-network environments;
+  any internet dependency MUST be declared with an offline or controlled alternative where required.
+- Logs and diagnostics MUST be actionable for support while respecting secret and personal-data
+  boundaries.
+- Performance, capacity, browser, hardware, and platform assumptions MUST be stated in each feature
+  specification when they affect customer outcomes.
+
+## Delivery Quality Gates
+
+1. **Specify**: define user journeys, edge cases, measurable outcomes, support impact, and explicit
+   exclusions before implementation planning.
+2. **Clarify**: resolve decisions affecting security, data, licensing, recovery, compatibility, or
+   customer-visible behaviour; unresolved decisions MUST NOT be silently guessed.
+3. **Plan**: map every affected surface, migration, rollback, observability change, documentation
+   update, and verification environment.
+4. **Implement**: preserve unrelated behaviour, avoid unnecessary rewrites, and keep changes small
+   enough to review and recover.
+5. **Verify**: run the specified tests and capture evidence for the primary journey, failure paths,
+   entitlement boundaries, upgrade/recovery impact, and packaged artifact when applicable.
+6. **Release**: review the complete diff and release impact. Commit, push, deploy, rebuild an ISO, or
+   change a live appliance only with explicit authorization for that action.
+
+Exceptions MUST identify the violated principle, customer or operational risk, mitigation, owner,
+and expiry condition. An exception without an expiry condition is invalid.
+
+## Governance
+
+This constitution governs feature specifications, plans, tasks, implementation reviews, and release
+decisions for this repository. When another local convention conflicts with it, this constitution
+takes precedence unless a documented exception is approved.
+
+Amendments require a written rationale, impact review, corresponding template updates, and explicit
+project-owner approval. Versions follow semantic versioning: MAJOR for incompatible governance
+changes or principle removal, MINOR for new principles or materially expanded obligations, and PATCH
+for non-semantic clarification. Every feature plan MUST perform the Constitution Check before design
+and again after design. Every release review MUST record compliance or approved exceptions.
+
+**Version**: 1.0.0 | **Ratified**: 2026-07-12 | **Last Amended**: 2026-07-12