CTC System Rebuild-Readiness Review Runbook¶

Status: CURRENT DOCUMENTATION REVIEW PROCEDURE
Audience: Product owner, Process owner, architecture/data owner, migration lead, operations/support owner and documentation integrator
Cross-family review: CROSS_FAMILY_RECONSTRUCTION_CONSISTENCY_REVIEW.md
Parent coverage: SYSTEM_RECONSTRUCTION_COVERAGE_MATRIX.md
Evidence register: REBUILD_READINESS_GAP_AND_EVIDENCE_REGISTER.md
Conflict register: DOCUMENT_AUTHORITY_CONFLICT_AND_RETIREMENT_REGISTER.md
Phase implementation: USER HOLD
Effects: repository documentation only unless the user separately authorizes an evidence package

1. When To Use This Runbook¶

Use this Runbook before:

selecting a React/Next.js migration capability;
accepting a source candidate;
declaring a Process M3/M4;
using a detailed packet as implementation authority;
retiring a PHP/API/helper/page/document path;
publishing a Runbook/Wiki page after a release;
planning a cross-family data or provider cutover;
designing a full-system rebuild or restore rehearsal.

Do not use it to activate a Phase or run an evidence package without explicit authorization.

2. Review Outcome¶

The review must end with one of:

READY FOR OWNER/POLICY REVIEW
READY FOR AUTHORIZED EVIDENCE PACKAGE
READY FOR ACTIVATED IMPLEMENTATION WAVE
REVISE DOCUMENTATION
BLOCKED BY POLICY
BLOCKED BY SOURCE DRIFT
BLOCKED BY SCHEMA/ENVIRONMENT UNKNOWN
BLOCKED BY ROLE/PROVIDER/PHYSICAL EVIDENCE
NOT APPLICABLE / RETAIN AS HISTORICAL

Do not report READY FOR IMPLEMENTATION merely because a packet is detailed.

3. Required Inputs¶

Collect:

current remote qa/master
selected family/capability/process ID
current source-authority document
original source baseline
current drift disposition
Product/Context/Design owner
current Process/data/interface owners
current Runbook/Wiki projection
current detailed coverage matrix
current policy matrix
current migration/parity/cutover matrix
current evidence state
current deployment/config/schema identity if known

For a source candidate, include exact branch/SHA and compare against current qa.

4. Review Sequence¶

Step 1 — Confirm current ref and work track¶

Record:

current qa/master SHA;
source/document-only range;
Phase implementation hold/activation state;
whether the task is documentation, evidence or implementation.

Stop if the requested action would modify Runtime while only documentation is authorized.

Step 2 — Resolve document authority¶

Read in order:

Product / Context
-> Roadmap/user hold
-> source authority
-> Process/data/interface owner
-> detailed capability packet
-> policy/parity/diagram packet
-> Runbook/Wiki projection
-> evidence register

Record conflicting documents in the conflict register. Do not silently choose the most recent file by modification date.

Step 3 — Review source baseline and drift¶

Classify:

NO RELEVANT DRIFT
DOCUMENTATION ONLY
SOURCE AFFECTED — RECONCILE
UNKNOWN — SOURCE REVIEW REQUIRED

For SOURCE AFFECTED, list:

changed files/functions/routes/tables;
changed state/transaction/effect/role behavior;
affected Process/Runbook/Wiki/migration packet;
whether current operator instructions remain safe.

Step 4 — Review Product and Process boundaries¶

Confirm:

intended business outcome;
non-goals;
trigger/preconditions;
normal/alternate/recovery path;
exact completion evidence;
non-implication;
next owner;
correction/reversal/compensation.

Stop if a business rule would be invented from legacy code shape or a tenant/customer ID.

Step 5 — Review actors and access¶

Confirm:

actor
subject
Tenant/profile
module/capability
page/API/action
record relation
record state
allowed/denied behavior
super-admin/office/recovery boundary

UI visibility is not sufficient. Backend authorization and record predicates must be documented.

Step 6 — Review data and state¶

Confirm:

authoritative records and IDs;
field dictionary and UOM/precision/default/null;
persisted versus derived state;
unique/index/concurrency assumptions;
mirrors/cache/projections;
audit/ledger/reversal;
retention/archive/backup impact;
MySQL and future PostgreSQL preservation.

Mark current schema facts RUNTIME EVIDENCE REQUIRED until verified in the named environment.

Step 7 — Review interfaces and transaction boundaries¶

For every query/command/event/effect confirm:

input/output DTO
validation
authorization
state predicates
transaction owner
concurrency/idempotency
exact readback
stable errors
timeout/partial recovery

No Route Handler, React component or generic helper should become business authority.

Step 8 — Review provider/file/physical boundaries¶

If applicable, separate:

local commit
provider attempt
provider acceptance
local provider reference
callback receipt/application
file object/metadata/link/readability
physical action/system state

Unknown provider/physical result blocks blind replay.

Step 9 — Review current UI, Runbook and Wiki¶

Confirm:

current route/page/labels;
loading/empty/denied/conflict/partial/success;
mobile/accessibility;
authoritative reread;
next role/process;
no-blind-retry wording;
current/future route separation;
actual Wiki DB/rendered/publication state.

A repository Wiki draft is not current published content.

Step 10 — Review target migration¶

Confirm:

React responsibility
Next.js adapter responsibility
TypeScript application/domain/policy
repository transaction
worker/effect responsibility
read shadow
one authoritative writer
cohort selector
rollback
caller-zero
legacy path retirement

Stop if dual-write or provider replay is required.

Step 11 — Review evidence¶

Map missing evidence to IDs in the evidence register.

At minimum distinguish:

source
schema/data
role/access
runtime
provider/file/physical
Wiki
release/deployment
backup/restore
migration
observation

Do not turn NOT_RUN into PASS.

Step 12 — Issue disposition¶

Use the completion template in Section 7.

5. Fast Consistency Checks¶

5.1 Current/future conflict¶

Search for combinations such as:

RELEASED + NOT IMPLEMENTED
MERGED + NOT MERGED
CURRENT + DETACHED CANDIDATE
PUBLISHED + T_WIKI_PAGE NOT READ
READY + RUNTIME EVIDENCE REQUIRED
COMPLETE INPUT + M4

5.2 Authority conflict¶

Search for:

same state owned by two tables/helpers
same command written by two routes
same provider effect replayed by two owners
same capability represented by module/config/client branch inconsistently
same current status in multiple navigation files

5.3 Recovery conflict¶

Search for:

retry whole flow after partial commit
Reopen described as reversal
Undo described as full rollback
source revert described as provider/data rollback
archive described as backup
service live described as ready

6. Minimum Evidence Before M3 And M4¶

M3 minimum¶

current source/schema identity;
accepted target-role normal and denied flow;
duplicate/timeout/partial/recovery;
provider/physical evidence where applicable;
current Runbook and Wiki wording reviewed;
cleanup/rollback readback;
owner acceptance.

M4 minimum¶

M3 evidence;
target query/command/repository packet;
selected cohort;
read parity;
one authoritative writer;
rollback without business/provider replay;
deployment/config/schema identity;
observation plan;
caller-zero and retirement plan;
backup/restore impact.

No current family is declared M4 by this documentation review.

7. Review Result Template¶

Capability / Process:
Review ref:
Original source baseline:
Current drift disposition:
Current Runtime/release state:
Current owner documents:

Documentation dimensions:
- Product:
- Roles/access:
- Process/state:
- Data/fields:
- Interfaces/errors:
- Effects/recovery:
- UI/Runbook/Wiki:
- Migration/rollback/caller-zero:

Conflicts corrected:
Conflicts deferred:
Open policy decisions:
Required evidence IDs:
Current M0-M5 disposition:

Decision:
READY FOR ... / BLOCKED BY ... / REVISE ...

Authorized effects performed:
Effects not performed:
Next owner:

8. Current Hold Boundary¶

This Runbook does not authorize:

source implementation;
DB read/write;
browser/role login;
provider calls/search/retry;
physical operation;
Wiki DB read/write;
deployment/service change;
backup/restore;
Phase activation.

Complete documentation review with available repository evidence and identify the exact evidence package needed next.

9. Maintenance¶

Update when:

status vocabulary changes;
a new family packet is added;
M3/M4 evidence requirements change;
current source authority changes;
a conflict class recurs;
migration/deployment/restore ownership changes.

---¶

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