# 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*