Skip to content

CTC Rebuild Bootstrap, Build, Deploy And Restore Sequence

1. Objective

A future team must be able to rebuild CTC deliberately from documented authority rather than copying legacy pages and helpers.

The sequence separates four concerns:

Bootstrap
= establish trusted identity, configuration, schema and authority

Build
= implement read/write/effect capabilities in dependency order

Deploy
= release one coherent source/config/schema/service set and prove readiness

Restore
= recover a complete bounded system and reconcile effects before traffic

No step may use a later layer to invent a missing earlier decision.

2. Global Stop Rules

Stop the affected sequence when:

  • Product/Profile applicability is unresolved;
  • tenant or record ownership is unknown;
  • current source and Process meaning conflict;
  • authorization would be inferred from menu/UI only;
  • a transaction or lower-bound invariant is not defined;
  • duplicate/timeout/unknown-result behavior is absent;
  • provider/physical replay is possible without reconciliation;
  • one-writer and rollback are absent;
  • current source baseline changed without revalidation;
  • required external effect lacks authorization;
  • complete restore dependencies are unknown for a cutover.

Do not resolve a stop by adding a generic framework, default allow, customer ID branch or hidden compensation.

3. Rebuild Stage Map

Stage Name Primary outcome Implementation status while hold applies
0 Authority and baseline freeze one current source/status owner documentation only
1 Deployment and tenant bootstrap portable deployment/tenant/config identity target contract only
2 Schema and authoritative data accepted MySQL schema/repository contract source characterization only
3 Identity and authorization actor/subject/tenant/action/record decision target contract only
4 Process/query read models deterministic source-backed reads packet preparation only
5 React + Next.js read-only shell current workflow presentation without writes not activated
6 First bounded transactional capability one command/repository writer requires M4 + activation
7 Audit/correlation/support traceable transition and recovery target contract only
8 Provider/file/device effects approved provider-scoped effect handling provider-specific activation only
9 Runbook/Wiki/role acceptance operable user procedure repository draft until authorized
10 Deployment/readiness/restore safe release and recovery evidence/rehearsal required
11 Cohort migration/caller-zero legacy writer retirement not activated
12 MySQL stabilization target runtime operational stability not activated
13 PostgreSQL transition separate DB migration conditional after Stage 12

4. Stage 0 — Authority And Baseline Freeze

Inputs

  • current Product, Context and Design;
  • current user activation/hold instruction;
  • current qa/master SHAs;
  • current Process and source-authority documents;
  • post-baseline source-delta register;
  • current external environment evidence where separately authorized.

Actions

  1. Record exact current source head.
  2. Identify the selected capability and Process owner.
  3. Identify all current source callers/writers/readers.
  4. Classify historical plans and source candidates.
  5. Reconcile later operational commits.
  6. Freeze the selected packet baseline and current delta state.
  7. Identify one writer for source, schema, Process, Wiki and final integration.

Output

CapabilityBaseline
  capabilityId
  processId/version
  sourceSha
  sourceFamilies
  currentWriters
  currentReaders
  currentStatusClass
  postBaselineDeltas
  openPolicies
  evidenceCeiling

Acceptance

  • no contradictory current/candidate/target status;
  • current source head named;
  • source-authority owner named;
  • Phase activation state named;
  • current operational deltas dispositioned.

5. Stage 1 — Deployment, Tenant And Configuration Bootstrap

Required authority

Deployment ID
Environment
Hosting Mode
Source Release
Config Release
Schema Release
Portable Tenant UUID
Runtime CLIENT_ID mapping
Operating Profile assignment
Module/Capability/Config resolution
Credential owner references

Current compatibility

Current PHP can start with external environment variables and deployment-local CLIENT_ID compatibility. That is not sufficient for a portable rebuild.

Target bootstrap order

sequenceDiagram
    participant OPS as Deployment Owner
    participant MAN as Deployment Manifest
    participant CFG as Config/Tenant Snapshot
    participant DB as MySQL
    participant APP as Runtime

    OPS->>MAN: select source/config/schema/deployment
    OPS->>CFG: publish/apply tenant mapping and non-secret config refs
    OPS->>DB: verify schema identity and tenant mappings
    OPS->>APP: start restricted runtime
    APP-->>OPS: source/config/schema/deployment identity

Output

  • immutable/derived Deployment Manifest;
  • local trusted tenant mapping;
  • typed effective config read model;
  • restricted runtime identity response;
  • safe credential availability references.

Prohibited shortcut

Config::CLIENT_ID
-> assumed portable tenant identity

6. Stage 2 — Schema And Authoritative Data

6.1 MySQL-first rule

MySQL remains authoritative through React + Next.js migration and stabilization.

6.2 Required per capability

  • authoritative entity/table;
  • stable identity and tenant key;
  • lifecycle/soft-delete;
  • states and valid transitions;
  • field types, precision, UOM, null/default;
  • unique/conditional integrity;
  • relationship and mirror rules;
  • audit/reversal/retention;
  • transaction and concurrency;
  • exact readback;
  • backup/restore inclusion.

6.3 Repository contract

Domain/Application
-> Repository interface
-> MySQL adapter

Do not expose table-shaped generic mutation as the target application contract.

6.4 Schema verification

Before a write wave:

expected schema
-> actual environment schema identity
-> migration state
-> compatibility readers/writers
-> rollback/fail-forward
-> fixture/residue plan

7. Stage 3 — Identity And Authorization

Required context

Physical Actor
Effective Subject
Tenant
Session
Impersonation/Override
Module/Capability
Action
Record
Record State
Config/Credential prerequisites

Required decision

ALLOW
DENY
UNAVAILABLE
UNKNOWN

UNKNOWN does not authorize a new consequential command.

Migration rule

  • current PHP session may remain initial authority;
  • Next.js may use a trusted bridge;
  • do not create independent PHP and Next.js session truths;
  • do not convert all legacy callers to fail-closed without caller evidence;
  • one page/API/action/record cohort at a time.

8. Stage 4 — Process And Query Read Models

Begin with read-only capability slices.

Query package

query name
actor/tenant/profile scope
input/filter/pagination/sort
source records
freshness/cutoff
persisted vs derived fields
empty/denied/unavailable
warnings/conflicts
stable DTO
current and target callers

Read-only acceptance

  • current source query characterized;
  • old/new parity on approved fixtures/records;
  • no hidden mutation;
  • tenant and role/record scope;
  • derived state explanation;
  • release/config/schema identity visible to support.

Preferred first read slices

  • list/detail/status read models;
  • queue projections;
  • diagnostic/effective-config views;
  • support timeline views.

Avoid choosing an external-effect or complex compensation workflow as the first reference.

9. Stage 5 — React + Next.js Read-Only Shell

React

  • component composition;
  • responsive/mobile behavior;
  • accessibility;
  • loading/empty/denied/unavailable/conflict states;
  • explicit current/derived status;
  • stable Runbook/Wiki link.

Next.js

  • App Router page/layout;
  • Server Component read path;
  • session/tenant/access adapter;
  • no-store operational queries where required;
  • safe error mapping;
  • current PHP coexistence link/route.

Boundaries

No new write
No generic Route Handler mutation
No provider replay
No PHP retirement
No PostgreSQL coupling

10. Stage 6 — First Bounded Transactional Capability

This stage requires explicit activation and accepted M4 packet.

Selection criteria

Choose a command with:

  • one clear Process owner;
  • one local DB transaction;
  • limited child effects;
  • exact readback;
  • reversible/rollback-safe cutover;
  • no unresolved provider/physical unknown;
  • target-role fixture path.

Command contract

requestToken
actor/tenant/action
record identity
expectedVersion/state
validated input DTO
transaction predicates
stable error
exact result DTO
transition/audit evidence
optional effect disposition

Cutover

read shadow
-> command shadow/compare without write where safe
-> one selected cohort writer
-> current and target result parity
-> observation
-> rollback or expansion

Prohibited

  • dual write;
  • hidden legacy fallback after target commit;
  • response-loss blind retry;
  • target code calling generic legacy mutation as its business contract;
  • broad multi-process first write.

11. Stage 7 — Audit, Correlation And Support

Required chain:

requestId
-> commandRequestToken
-> processInstanceId/correlationId
-> auditId
-> providerAttemptId / file/device evidence

Support must be able to answer:

  • what current business row says;
  • which transition committed;
  • which effect boundary was crossed;
  • whether provider/physical/file work may have happened;
  • which step can safely resume;
  • which action must not be repeated.

Do not treat request logs or notification ACK as business approval.

12. Stage 8 — Provider, File, Device And Worker Effects

Only approved effect families enter this stage.

Required provider packet

EffectIntent identity
Attempt identity
Credential owner
Provider request identity
Provider idempotency/search
Timeout/unknown classification
Callback receipt/apply
Local result save
Retry/backoff/manual review
Compensation
Audit/evidence
Worker deployment/readiness

Worker rule

A shared Node.js worker runtime may provide execution mechanics. Each provider/process owner retains business effect policy.

Worker runtime
!= generic outbox/business authority

File rule

Object
-> Metadata
-> Business Link
-> Readability
-> Cleanup/Retention

Each checkpoint can fail independently.

13. Stage 9 — Runbook, Wiki And Role Acceptance

Repository source

Update:

  • Process contract;
  • operator/admin Runbook;
  • diagrams;
  • Wiki projection;
  • status/terminology;
  • current/future route;
  • exception/recovery;
  • known limitations.

Publication

current T_WIKI_PAGE read
-> bounded draft diff
-> Process review
-> target-role review
-> named-slug authorization
-> write once
-> DB readback
-> rendered page readback
-> findability/mobile review
-> observation/rollback

Repository draft is not publication.

14. Stage 10 — Deploy, Readiness And Restore Rehearsal

14.1 Deployment

approved source/config/schema manifest
-> deploy selected services
-> observed runtime identity
-> liveness
-> readiness/dependencies
-> read-only canary
-> transactional canary
-> target-role acceptance
-> observation

14.2 Backup set

A complete recovery set includes the selected capability's:

  • DB recovery point;
  • archive family where applicable;
  • file/object inventory/snapshot;
  • config release/reference;
  • credential recovery/rotation plan;
  • source/artifact and schema manifest;
  • provider reconciliation references;
  • required audit/evidence;
  • cleanup/retention/legal-hold state.

14.3 Isolated restore

Restore into a restricted target with traffic, callbacks, schedulers and provider sends disabled.

Do not call the system restore-ready until data/file/config/provider reconciliation and canaries pass.

15. Stage 11 — Cohort Cutover And Caller-Zero

Cohort

A cohort is explicit:

tenant/profile
+ role/action
+ process/capability
+ route/caller set
+ record set if required

One writer

cohort selected
-> old or new writer
-> never both

Caller-zero

Prove:

  • route callers zero;
  • PHP helper callers zero;
  • legacy mutation callers zero;
  • scheduled/provider callback callers migrated;
  • old UI entry retired/redirected;
  • Wiki links updated;
  • rollback window closed or fail-forward accepted.

16. Stage 12 — React + Next.js + MySQL Stabilization

Required before PostgreSQL:

  • role/process acceptance;
  • sustained error/latency/unknown-result evidence;
  • provider/file/device stability;
  • backup/restore rehearsal;
  • operational Runbook acceptance;
  • PHP caller-zero for selected capability;
  • no unresolved data parity;
  • accepted support/on-call path.

17. Stage 13 — PostgreSQL Transition

PostgreSQL is a separate database program.

Required inputs:

  • stabilized application/repository contract;
  • accepted MySQL semantics;
  • precision/UOM/timezone/collation rules;
  • identity/sequence/UUID mapping;
  • generated columns/index/conditional uniqueness translation;
  • migration/reconciliation/failback;
  • complete backup/restore;
  • accepted capability parity suites.

Do not use PostgreSQL migration to solve unresolved Process or generic-mutation problems.

18. Current Application Startup Order

Current PHP compatibility runtime, when deployed, conceptually depends on:

external environment and secrets
-> PHP-FPM/Apache
-> session/config bootstrap
-> MySQL connection
-> page/API route registries
-> module/menu/access guards
-> current module helpers
-> file/provider adapters
-> JSONL/service diagnostics

This is current topology evidence, not the target domain dependency graph.

19. Target Service Startup Order

1. config/credential references mounted
2. DB/schema compatibility available
3. migration/apply owner completes
4. Web/API starts NOT_READY
5. worker/gateway starts NOT_READY or disabled
6. runtime identity/readiness checks pass
7. provider callbacks/routes verified without live replay
8. read-only traffic/canary
9. transactional cohort traffic
10. approved schedulers/workers/providers enabled
11. observation

20. Restore And DR Order

incident/rehearsal declared
-> source/effect freeze
-> backup set selected
-> isolated target
-> DB restore
-> archive reconcile
-> file/object restore
-> config/credential recovery
-> compatible source/schema deploy
-> provider/callback/outbox reconcile
-> restricted readiness
-> read-only canary
-> transactional canary
-> schedulers/workers/providers one family at a time
-> traffic cutover
-> observation and measured RPO/RTO

Failback repeats the same discipline in the reverse target direction. It is not a DNS-only action.

21. Evidence Required At Every Stage

source SHA
config/schema/deployment identity
actor/tenant/role/record
normal and denied result
exact authoritative readback
partial/unknown recovery
cleanup/residue
rollback/fail-forward
owner acceptance

Unexecuted evidence remains NOT_RUN or REQUIRED, never PASS.

22. Current Hold Boundary

The sequence is an architectural and operational specification only.

While the current hold applies:

  • Stage 0 documentation may proceed;
  • source delta/register/Runbook/Wiki drafts may proceed;
  • evidence packages may be defined;
  • no Stage 1+ implementation is activated by this document.

23. Maintenance

Update this sequence when:

  • the target architecture changes;
  • Phase execution is reactivated;
  • a first read/write/provider wave is selected;
  • current deployment/recovery topology changes;
  • a family reaches M3/M4/M5;
  • PostgreSQL transition is activated.

---

Source: docs/reconstruction/REBUILD_BOOTSTRAP_BUILD_DEPLOY_RESTORE_SEQUENCE.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.