CTC Wiki DB Same-Delivery Synchronization Policy¶

Status: CANONICAL CURRENT WIKI PUBLICATION RULE
Effective date: 2026-08-11
Durable source: Current Context §§13, 19
Decision history: Context History
Deployment rule: .agents/rules/DEPLOYMENT_DB_WIKI_CONTINUITY.md
Task overlay: DEPLOYMENT_DB_WIKI_REQUIREMENTS.md
User-content store: deployed Production T_WIKI_PAGE, rendered through the Operations Manual
Owns: standing authorization for bounded existing-slug synchronization and new stable-slug creation, decision boundaries for structural/access changes, readback and rollback
Does not own: Process semantics, current Runtime facts, role/access policy, new-page selection, Task status or DB credentials

This policy supersedes older repository-Wiki wording that says every T_WIKI_PAGE update always requires a new per-release approval.

1. Default¶

When a deployed change affects user-facing operation:

exact existing mapped Wiki slug
= update in the same delivery by default

exact bounded new stable Wiki slug
= create in the same delivery by default

The same-delivery target is the deployed Production Wiki row, never a local development database. A local Wiki row may support a disposable test only; it does not satisfy publication, readback, or recovery for the release. If the exact existing slug is absent in Production, capture that absence and create one bounded stable slug instead of leaving the operator change undocumented.

When a change is internal-only, agent-only, architecture-only or has no user-facing procedure impact:

Wiki sync = NOT_APPLICABLE

The default does not authorize publishing unverified target design as current behavior.

2. Standing Authorization Scope¶

No second confirmation is needed to update an existing T_WIKI_PAGE row or create one bounded new stable row when all apply:

exact existing slug is named in the Task/handover;
source/Process/role authority is resolved;
content describes verified current behavior released by the same delivery;
previous row/content/hash is captured, or absence is captured for a new slug;
a new slug inherits the current tenant's existing Operations Manual visibility and maps only to an already accessible application page when mapped;
change does not rename, retire or delete a slug;
change does not alter tenant/role visibility, page access or navigation authority;
no credential, secret, raw ID, source path, table/API internals or incident-sensitive evidence is exposed;
one bounded write is followed by DB readback;
rendered-page readback is performed when an authenticated channel exists.

The standing authorization includes correction of labels, normal steps, input meaning, visible result, retry/recovery and current limitations on the exact mapped page.

3. Explicit User Decision Required¶

Return WIKI_DECISION_REQUIRED before:

renaming, retiring, deleting or redirecting a page;
changing role or tenant visibility;
changing menu/navigation ownership;
bulk publishing unrelated pages;
publishing a page whose Process/source authority is disputed;
publishing internal agent/security/credential/incident material;
replacing verified current content with target/future design.

A Task may contain the exact user decision in advance; no second confirmation is needed when that decision is already explicit.

4. Impact Classification¶

NOT_APPLICABLE
UPDATE_EXISTING_REQUIRED
CREATE_NEW_REQUIRED
CREATE_OR_RETIRE_DECISION_REQUIRED
SYNC_BLOCKED
COMPLETE

Change	Classification
Agent governance or internal code-quality policy	`NOT_APPLICABLE`
Existing operator button/result/error/recovery changes	`UPDATE_EXISTING_REQUIRED`
Existing role quick-start steps change	`UPDATE_EXISTING_REQUIRED`
Verified current procedure with no mapped page	`CREATE_NEW_REQUIRED`
Page visibility must change	`CREATE_OR_RETIRE_DECISION_REQUIRED`
Exact update prepared but DB/auth channel unavailable	`SYNC_BLOCKED`
DB and required rendered readback completed	`COMPLETE`

5. Same-Delivery Sequence¶

identify affected Process and exact existing or new slug
-> prepare bounded content diff
-> capture previous row/content/hash
-> complete qa/master Git deployment
-> update or create the exact Production Wiki row once
-> reread exact DB row/hash
-> reread rendered page when available
-> verify links/findability for affected role when in scope
-> record rollback

Do not publish ahead of source when doing so would describe behavior that is not released.

A documentation-only delivery may update an existing administrator/support page in the same set when the user-facing content itself is the approved outcome.

6. Content Boundary¶

Every updated page states only what the intended reader needs:

when to use
who acts
where to enter
current required versus optional input
primary action
visible result
authoritative reread
next step
error/partial/unknown meaning
retry/recovery
current limitations

Do not publish:

repository paths or Task IDs as normal user guidance;
numeric tenant IDs or raw account/session details;
credentials, tokens, cookies or provider secrets;
raw table/API/evidence payloads;
unverified access policy;
target-only features presented as current;
internal security findings or exploit detail.

7. Unknown Result And Retry¶

After a Wiki write timeout or ambiguous response:

stop replay
-> reread exact slug/row/hash
-> compare expected content hash/version
-> classify APPLIED / MISSING / PARTIAL / UNKNOWN
-> repeat only the missing bounded owner step

Do not create duplicate pages or revisions because the first result was unknown.

8. Rollback¶

Wiki rollback uses the captured prior row/content and the same exact slug.

source rollback deployed
-> restore affected Wiki content when current guidance changed
-> DB row readback
-> rendered readback when available

Do not roll back unrelated pages.

9. Urgent Operational Fix Exception¶

A safe outage correction is not delayed only because Wiki synchronization is temporarily unavailable.

Required result:

Git deployment: COMPLETE
Wiki sync: SYNC_BLOCKED
exact pending slug/content/rollback: PRESERVED
completion: PARTIAL — WIKI CONTINUATION REQUIRED

Resolve the Wiki continuation when the channel is available. Do not call the total user-facing delivery complete while the required page remains stale.

10. Evidence Levels¶

repository mapping/draft
!= T_WIKI_PAGE write
!= DB readback
!= rendered readback
!= target-role findability
!= field acceptance

Report each level honestly.

---¶

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