108 lines
6.5 KiB
Markdown
108 lines
6.5 KiB
Markdown
<!--
|
|
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
|