# INVEETAIRE ## AI DEVELOPMENT CONSTITUTION Version : 1.1 Status : ACTIVE Project : Inveetaire – Wedding Management Platform This document defines how every AI assistant must contribute to the Inveetaire platform. It is mandatory for: - Claude - ChatGPT - Antigravity - Cursor - GitHub Copilot - Future AI Assistants This document does not replace PRD, SAD, DDD, PDD, DBP, ADR, MIB, or TCS. It defines HOW AI should work with those documents. Change History: Version 1.0 — Original constitution. Version 1.1 — Synchronized with DESIGN_REVISION_PACK_v2.0. Added Section 28 (Implementation Authority Hierarchy). Strengthened Section 25 (File Creation Boundaries — examples and prerequisites). Strengthened Section 27 (Automatic Stop Conditions — documentation conflict). --- # 1. PROJECT IDENTITY Project Name Inveetaire Product Wedding Management Platform Core Promise One Wedding. One Workspace. Everyone Aligned. Technology Stack Backend Native PHP 7.4 Frontend HTML5 TailwindCSS Alpine.js FontAwesome Database MariaDB / MySQL Hosting Shared Hosting (cPanel) Future Laravel Ready React Ready PostgreSQL Ready --- # 2. PRODUCT PHILOSOPHY Never forget: Technology supports the event. It never stops it. Shared operational awareness is more valuable than automation. Guests should experience zero friction. One Guest One URL One QR One Journey. The couple personalizes content. The product owns design. Vendor Management is not accounting. Offline resilience is mandatory. Every architectural decision must support a real wedding with hundreds of guests. --- # 3. DOCUMENT AUTHORITY This section governs the priority of product and architecture documents. When documents conflict, the following order applies. 1 PRD 2 SAD 3 DDD 4 PDD 5 DBP 6 ADR 7 MIB 8 TCS 9 AI.md AI must NEVER invent requirements. If conflict exists, STOP. Explain. Wait for approval. Never guess. See also Section 28 for the implementation-time authority hierarchy that governs conflicts between task prompts, sprint plans, and architecture documents. --- # 4. REQUIRED READING ORDER Before writing any code. Read: PRD ↓ SAD ↓ DDD ↓ PDD ↓ DBP ↓ ADR ↓ MIB ↓ TCS ↓ Implement --- # 5. AI WORKFLOW Every coding session follows: Understand Task ↓ Locate MIB Task ID ↓ Read related PRD section ↓ Read Architecture ↓ Read Database ↓ Read Coding Standards ↓ Implement ↓ Review ↓ Test ↓ Stop One AI Session = One Task Never multiple Tasks. --- # 6. IMPLEMENTATION RULES AI MUST Follow PRD Follow SAD Follow DDD Follow PDD Follow DBP Follow ADR Follow MIB Follow TCS Never redesign architecture. Never rename database tables. Never rename modules. Never rename routes. Never rename folders. Never rename services. Never rename models. Never invent features. Never skip validation. Never skip audit logging. Never bypass Service Layer. Never access Models from another Module directly. Never place SQL inside Controllers. Never place SQL inside Views. Never place Business Logic inside Views. Never duplicate code. Never hardcode configuration. Never hardcode Workspace IDs. Never create hidden dependencies. --- # 7. ARCHITECTURE RULES Controllers Receive Request Validate Call Service Return Response Only. Services Contain all Business Logic. Models Only Database Access. Views Display Data Only. Helpers Reusable Utility Functions. Middleware Authentication Authorization Workspace Validation CSRF Session No exceptions. --- # 8. MODULE RULES Every feature belongs to ONE module. Never create a module without approval. Never implement functionality outside the owning module. Cross-module communication must happen through Services. Never call another module's Model. --- # 9. DATABASE RULES Always use parameterized PDO. Always use Transactions for multiple writes. Always filter by Workspace. Always respect Soft Delete. Never use SELECT * Never concatenate SQL. Never bypass Models. Future PostgreSQL compatibility must be preserved. --- # 10. SECURITY RULES Always validate input. Always escape output. Always verify Workspace ownership. Always verify permissions. Always log sensitive actions. Protect against CSRF XSS SQL Injection Session Fixation Unauthorized Access Never trust Client Data. --- # 11. FRONTEND RULES Use TailwindCSS. Use Alpine.js. No Bootstrap. Responsive First. Accessibility matters. Components are reusable. Never duplicate UI. --- # 12. CODE QUALITY Readable code. Small functions. Thin Controllers. Business Logic in Services. No commented-out code. No TODO before merge. No dead code. No magic numbers. Meaningful variable names. Early return preferred. --- # 13. WORKSPACE ISOLATION Every Workspace is isolated. Every Workspace owns: Guests Invitation Vendor Dashboard Media Reports No Workspace may access another Workspace. No exception. --- # 14. GUEST EXPERIENCE Guests never create accounts. Guests receive One URL. One QR. One Invitation. One Reminder. Invitation content is rendered dynamically based on assigned Wedding Events. Operational data remains Event-specific. --- # 15. CODING SESSION FORMAT Every AI response should end with: Task ID Summary Files Created Files Modified Dependencies Acceptance Criteria Security Checklist Definition of Done Remaining Tasks --- # 16. DEFINITION OF DONE A task is COMPLETE only if ✔ Acceptance Criteria passed ✔ Security verified ✔ Workspace isolation verified ✔ Validation completed ✔ Audit logging implemented ✔ No debug code ✔ No TODO ✔ PHPDoc completed ✔ Manual testing completed ✔ MIB task completed ✔ TCS compliant --- # 17. IF AI IS UNSURE Never guess. Never redesign. Never improvise. Instead: Explain State assumptions Ask Wait --- # 18. FUTURE COMPATIBILITY Every implementation should preserve future migration to Laravel React PostgreSQL API Mobile App Do not optimize for future at the expense of MVP simplicity. --- # 19. AI STARTUP CHECKLIST Before coding □ Read AI.md □ Read MIB □ Read related PRD □ Read related ADR □ Read related TCS □ Understand Acceptance Criteria □ Identify Task ID □ Start implementation --- # 20. AI COMPLETION CHECKLIST Before saying DONE □ No TODO □ No Debug Code □ No var_dump □ No die □ PHPDoc Complete □ Workspace Filter Applied □ Validation Complete □ Audit Complete □ Acceptance Criteria Passed □ Manual Test Completed □ Ready for Merge --- # FINAL PRINCIPLE The Product is frozen. The Architecture is frozen. The Database is frozen. Implementation evolves. The principles do not. Every line of code must make the platform easier to maintain, easier to understand, and easier to evolve. If an implementation violates these principles, it is wrong, even if it works. --- # 21. GIT OPERATIONS AI must NOT execute git commands unless EXPLICITLY instructed by the user. The following git operations require an EXPLICIT user instruction: git add git commit git push git pull git merge git rebase git reset git branch (create or delete) AI may READ git state freely: git status git log git diff When a task is complete, AI must prepare a commit message suggestion. AI must NOT execute the commit. AI must wait for the user to confirm or instruct. NEVER force push without explicit user instruction. --- # 22. TASK BOUNDARIES Every AI session implements EXACTLY ONE Task ID. When the task is complete: AI must STOP. AI must present the completion summary. AI must NOT proceed to the next task. AI must NOT perform adjacent tasks to save time. AI must NOT add features not in the Task ID scope. The user decides when the next task begins. Not the AI. --- # 23. APPROVAL CHECKPOINTS AI must STOP and WAIT for explicit approval before: 1. Starting ANY implementation 2. Executing ANY git commit or push 3. Creating ANY file not listed in the Task ID scope 4. Making ANY decision not documented in PRD, SAD, DBP, ADR, or MIB 5. Modifying ANY file outside the current Task ID 6. Updating ANY AI documentation (AI.md, WORKFLOW.md, etc.) 7. Starting the next task after completing the current one Explicit approval means: The user has typed a clear instruction in the current message. Implicit approval does NOT exist. A previous message that said "go ahead" does NOT authorize future tasks. Each task requires its own approval. --- # 24. TERMINAL USAGE AI may execute terminal commands freely for READ-ONLY operations: Checking file structure Reading git status Running PHP lint and syntax checks Verifying file contents AI must STATE the command and WAIT for approval before executing: Creating or deleting directories or files Running git add, commit, or push Running database commands Running package installation commands (npm, composer) Any command that modifies the filesystem If a terminal command fails, AI must: 1. Report the failure clearly 2. Explain the cause 3. Propose the fix 4. Wait for approval before retrying --- # 25. FILE CREATION BOUNDARIES AI may only create files that are: 1. Explicitly listed in the current Task ID Files Expected section in MIB 2. Explicitly requested by the user in the current message AI must NOT create files that are: Scoped to a future Task ID Not listed in the Task ID specification Helper or utility files invented by the AI If AI determines that an unlisted file is required: STOP. Explain why the file is needed. Reference the documentation gap. Wait for approval. Adding a file without approval is a scope violation, even if the file appears beneficial. --- ## 25a. EXAMPLES ARE NOT DELIVERABLES Documentation examples — code snippets, sample configurations, illustrative file structures — are illustrative only. They must NEVER be interpreted as implementation artifacts. Only "Files Expected" defines implementation scope. If an example appears in documentation and is not listed under "Files Expected" for the current Task ID, AI must NOT create it. --- ## 25b. IMPLICIT PREREQUISITES If a task requires a helper, utility, configuration key, bootstrap dependency, or any supporting artifact that: - is not listed in the current Task ID "Files Expected" - does not already exist in the codebase AI must: STOP. Explain what is missing and why it is required. Reference the documentation rule or functional requirement that demands it. Wait for explicit approval before creating it. Silent introduction of unlisted artifacts is a scope violation, regardless of whether the artifact is beneficial. --- # 26. DOCUMENTATION UPDATES AI.md, WORKFLOW.md, PROMPT_LIBRARY.md, and all docs/ai/ documents are FROZEN unless the user explicitly requests an update. AI must NEVER modify documentation files during a coding session. AI must NEVER add rules or explanations to documentation files without explicit instruction. If AI identifies a gap in the documentation: Report it in the task summary. Do NOT auto-patch it. Wait for the user to instruct. --- # 27. AUTOMATIC STOP CONDITIONS AI must STOP IMMEDIATELY when any of the following is true: 1. The Task ID implementation is complete 2. The user has included the phrase "Wait for approval" 3. The user has included the phrase "Do not continue" 4. An implementation decision requires choosing between options not covered by documentation 5. A file conflict is detected 6. A git command would affect the remote repository 7. The scope would expand beyond the current Task ID 8. A documentation conflict is detected between any two documents at different levels of the authority hierarchy (see Section 28) When stopped, AI must: Present the completion summary in the required format. Wait silently. NOT continue work in the same response. NOT hint at what it will do next. NOT ask "Shall I continue?" — the user decides. --- # 28. IMPLEMENTATION AUTHORITY HIERARCHY This section governs conflicts between implementation-time documents: task prompts, sprint execution plans, and architecture documents. It is separate from Section 3, which governs product and architecture document priority. When any lower-level document conflicts with a higher-level document, AI must NOT follow the lower-level document. The authority hierarchy for implementation-time decisions is: AI.md ← Highest authority ↓ ADR ↓ MIB ↓ Sprint Execution Plan ↓ Implementation Prompt ↓ Implementation ← Lowest authority --- ## Conflict Protocol When a conflict is detected between any two levels: 1. STOP. Do not implement. 2. Identify which two documents conflict. 3. State the exact conflicting text from each document. 4. Report the conflict clearly to the user. 5. Wait for explicit approval before proceeding. Never resolve a documentation conflict by choosing the most recent document. Never resolve a documentation conflict by choosing the most permissive option. The human decides. --- ## Implementation Prompts Are Execution Instructions Only An implementation prompt is a task-level instruction. It defines WHAT to implement within a session. It does NOT override: AI.md ADR MIB Sprint Execution Plan If an implementation prompt contradicts any of the above, STOP. Report the conflict. Wait for approval. --- ## Architecture Decisions May Not Be Inferred If documentation leaves multiple valid implementations, AI must NOT choose between them. STOP. Present the options. Request human approval. Never select an implementation approach that is not explicitly documented or explicitly approved. --- ## CLI Validation Test Scaffold All PHP CLI validation scripts must follow the boot-before-echo pattern. Bootstrap::init() must be called and its output discarded before any echo statement: 1. ob_start() 2. $bootstrap->init() 3. ob_end_clean() 4. — echo output is safe from here Non-compliance produces spurious "headers already sent" PHP warnings in CLI contexts that do not reflect application behaviour. --- *Ref: DESIGN_REVISION_PACK_v2.0 — REV-022, REV-023*