Codex Handover Prompt — The Grand Project
Work on **The Grand Project** located at:
`C:\Users\Administrator\Desktop\Storage\Projects\The Grand Project`
Treat:
`GRAND-PROJECT-SPECIFICATION.md`
as the **single authoritative source of truth** for architecture and requirements.
Supporting files:
- `ARCHITECTURE.md`
- `DEPENDENCIES.md`
- `SECURITY.md`
- `todo.md`
- `updates.md`
- `decisions.md`
If any supporting file conflicts with `GRAND-PROJECT-SPECIFICATION.md`, the master specification wins.
Your job
Implement the Grand Project foundation in controlled phases. Do not attempt to build all Plugin Modules at once.
Before changing anything:
1. Read the complete master specification.
2. Audit the existing project folder if files already exist.
3. Preserve existing completed work that complies with the specification.
4. Do not rewrite working architecture merely because you would structure it differently.
5. Record meaningful implementation decisions in `decisions.md`.
6. Keep `todo.md` and `updates.md` current.
Non-negotiable architecture rules
- All installable applications are **Plugin Modules**.
- Core infrastructure services belong under `Core System Services`.
- Plugin hard dependencies are declared in `plugin.json`.
- Never create undeclared hard dependencies.
- Never directly query or modify another plugin's tables.
- Cross-plugin interaction uses framework services, capabilities, APIs, events, jobs or workflows.
- Each business record has one authoritative owner.
- Do not store uploads in plugin source directories.
- Do not store mutable configuration in files that normal updates overwrite.
- Do not store credentials/secrets in source or manifests.
- Use migrations for all schema changes.
- Do not weaken authentication, tenant isolation, permissions or policies for convenience.
- Add automated tests alongside implementation.
- Do not invent speculative features outside the specification.
- Do not silently remove or simplify requirements.
Required implementation sequence
Phase 1
Build the framework skeleton:
- canonical directory structure
- bootstrap
- config/environment
- request/response
- router
- middleware
- database abstraction
- structured logging
- request/correlation IDs
Phase 2
Build identity/authorisation integration:
- Central Authentication integration contract
- user context
- company/relationship context
- roles
- permissions
- policies
- service identities
Phase 3
Build the plugin runtime:
- canonical `plugin.json` schema
- manifest validator
- plugin discovery
- plugin registry
- dependency resolver
- capability registry
- install/enable/disable lifecycle
- reverse-dependency checks
- dependency lock file
Phase 4
Build shared runtime services:
- events/outbox
- queues/workers
- scheduler
- workflow/saga support
- storage/file abstraction
- PDF/document service
- notifications/email
- audit
- secrets/config
- feature flags
Phase 5
Build installation/update/recovery:
- web/CLI/unattended installer
- Update Server client
- signed package verification
- staging/current/previous release model
- mandatory restore points
- migrations in dependency order
- post-update health checks
- automatic rollback
- independent recovery utility
Phase 6
Build Administration:
- health dashboard
- Plugin Module manager
- dependency map
- updates
- backup/restore
- queue/scheduler/workflow monitoring
- integrations
- credentials
- AI agents
- logs/audit
- diagnostics
- security centre
Phase 7
Create a deliberately small **Test Plugin Module** that exercises:
- manifest
- migration
- route
- permission
- capability/service
- event
- queue job
- storage
- configuration
- health check
- install
- disable
- update
- rollback
- uninstall
Do not begin broad business Plugin Module development until this contract is working and tested.
First real business modules after framework validation
Recommended sequence:
1. Products
2. Asset Registry
3. ServiceVault
This sequence must prove both the product/inventory data model and a genuine hard Plugin Module dependency.
Verification requirements
For each development batch:
- run relevant syntax/lint checks
- run static analysis if configured
- run unit/feature/integration tests
- run Plugin Module contract tests where applicable
- verify tenant isolation for company-scoped code
- verify migrations
- verify manifest/dependency integrity
- update `todo.md`
- update `updates.md`
- record architecture decisions in `decisions.md`
Deliverables from each batch
Report:
1. What changed.
2. Files changed/created.
3. Tests/checks performed.
4. Any unresolved risks or specification conflicts.
5. Updated `todo.md` status.
6. The exact next recommended phase.
Do not claim work is complete unless it is present and verified in the project.