<callout icon=\"⚙️\" color=\"gray_bg\">
\tExecution Protocol Layer — not a design document.
\tThis document defines how CFP+ builds the Notion website in a controlled, auditable loop.
</callout>
CFP+ Website Implementation System v1.0 (Activation Phase)
Status
Draft
Source Of Truth
No
0) Role Boundary (Locked)
This document answers:
•How to execute the website build on Notion.
•How to collect evidence to verify requirements.
•How to apply translation during build without duplicating truth.
•How to preserve cross-link integrity.
This document does not answer:
•What the website *means* (Mission).
•What must be proven (Requirements).
•How UI should look (Design System).
1) Operating Principle
Build-to-verify loop is always active:
Requirement
↓
Implementation
↓
Evidence
↓
Verification
↓
Iteration (execution only)
No reverse edits:
•Implementation must not rewrite Mission.
•Implementation must not rewrite Requirements.
•Design patterns must not rewrite Governance.
2) Entry Domains (Activation Scope)
2.1 Notion build templates (page instantiation rules)
•Use the approved Page Types Registry to choose the page type first.
•Instantiate pages using the approved Component Pattern Library.
•Use a standard “page header block” (recommended):
\t- Page type
\t- Owner
\t- Status (Draft/In Review/Published)
\t- Source reference (canonical)
2.2 Evidence capture workflow (proof collection standard)
For each requirement verification event, capture:
•Evidence URL(s) (published page links)
•Screenshot(s) if needed
•Registry record ID(s) / source reference link(s)
•Test record (click-path test, mobile check, etc.)
•Verification decision (Verified / Non-conformant / Waived)
2.3 Translation application layer (multi-language instantiation)
•One architecture, multiple languages.
•Do not create separate “websites” per language.
•Each translated page must reference its canonical source.
•Structural parity must be preserved (same outline / headings / placeholders).
2.4 Cross-link integrity rules (knowledge graph consistency)
•All internal links must point to canonical targets (no duplicate truth pages).
•“Related content” must be implemented consistently.
•Any renamed/moved page must keep references valid (log old/new path).
2.5 Build-to-verify loop (continuous audit during construction)
•Every build step should map to at least one requirement domain:
\t- WEB-REQ-FUNC / CONT / ARCH / AI / GOV
•Verification is incremental: requirement-by-requirement.
3) Controlled Change Classification (Operational)
All changes during implementation must be classified:
1) Governance change → Baseline Review required (Mission / frozen navigation / language baseline).
2) Design change → Design System log (pattern/layout changes within allowed scope).
3) Implementation change → Evidence update only (build artifacts, links, test records).
4) Minimum Implementation Artifacts (v1.0)
•Home page (stub or live) following Home Page type.
•Section landing pages (stubs ok).
•Knowledge Article template page.
•FAQ page template.
•Evidence log records for initial requirements (at least:
\t- WEB-REQ-FUNC-001
\t- WEB-REQ-CONT-001
\t- WEB-REQ-ARCH-001
\t- WEB-REQ-AI-001
\t- WEB-REQ-GOV-001)
5) Exit Criteria (Activation Complete)
Activation Phase is complete when:
•Core page types exist as stubs/templates.
•Navigation registry is implemented without renaming.
•Evidence records exist for the initial “foundation” requirements above.
•Translation structure is ready for VI/EN instantiation.