CTC Live Operation Continuity And Restriction Policy Review¶

Classification: CURRENT EXECUTION-GOVERNANCE AND LIVE-SAFETY REVIEW
Status: DETAILED CURRENT INPUT / PHASE IMPACT NONE
Review date: 2026-08-10
Reviewed integration baseline: qa@8e06dccb4a4045254ad6d8632648ce51ce0d9a0e
Production release baseline at review start: master@1479c52d7ed24deadc4f75d39583ab0104f51680
Durable correction: Context Appendix Q
Canonical rule: .agents/rules/LIVE_OPERATION_CONTINUITY.md
Task overlay: docs/tasks/RESTRICTION_DELTA_REQUIREMENTS.md
P2-007 addendum: docs/tasks/P2-007/LIVE_OPERATION_RESTRICTION_PRESERVATION.md
Effects in this review: repository documentation and local validation wiring only; Runtime/DB/role/menu/API/config/account/provider/service/Wiki/deployment/physical effects NONE

1. Executive Finding¶

The prior CTC guidance already contained partial live-operation safeguards, but it remained too easy for an agent to reinterpret broad terms such as security, authorization, integrity, least required access, hard block, and expected deny as permission to introduce restrictions.

The gap was material because CTC is a live shared system and previous AI-assisted changes had already produced outages through broad role/API guards and unrequested validation/input changes.

Review result:

existing operation-preservation intent
= PRESENT

explicit default RESTRICTION DELTA = NONE
= MISSING BEFORE THIS CORRECTION

existing-control preservation vs new-control authorization
= NOT SUFFICIENTLY SEPARATED

required field/access/state delta ledger in every Task
= MISSING

positive allow-path evidence before deny changes
= PARTIAL

security finding -> report/decision rather than silent implementation
= MISSING

implementation vs deployment vs restriction authorization
= PARTIAL

P2-007 ambiguous access/hard-block wording
= REQUIRED ADDENDUM

The correction does not weaken existing security. It prevents an agent from creating or deploying new policy without user approval.

2. User-Reported Failure Pattern¶

The repeated failure pattern is:

user requests feature/fix/refactor
-> agent notices or imagines validation/security/access concern
-> agent adds required field, guard, denial, or precondition
-> tests are authored to assert the new restriction
-> implementation passes those tests
-> candidate is deployed with a broader shared effect
-> normal Client 1 operation fails
-> user reports outage
-> another hotfix removes or weakens the restriction

The failure is not solved by adding more generic reminders to “be careful.” It requires a durable authorization boundary and a Task-level delta ledger.

3. Current Guidance That Was Helpful But Insufficient¶

3.1 Existing helpful rules¶

Before this correction, current guidance already said:

preserve Client 1 as the live regression reference;
do not add broad role/page/API default denial;
unknown caller plus proposed denial is a stop condition;
derive/default/empty/draft input before hard blocking;
do not allow optional post-write sync to roll back primary work;
deployment and DB/provider/Wiki effects require separate authorization;
Task files must be detailed;
Work Graph requires manifest accounting and independent verification.

These are retained.

3.2 Remaining ambiguity¶

The following language was still unsafe when interpreted by an agent:

hard block only for security, authorization, concrete data-integrity,
physically impossible or irreversible-effect risk

The agent could decide for itself that an inferred condition was security or integrity related.

Similarly, P2-007 language such as:

least required access
expected allow/deny
foreign-reference rejection
role/API parity

could be used to justify an unrequested access policy rather than documenting current behavior.

The correction changes the decision owner:

agent identifies concern
!= agent owns restriction policy

user explicitly approves exact restriction
= restriction may enter Task scope

4. Restriction Classes Added To Governance¶

The correction now treats all of the following as explicit restriction changes:

optional-to-required field changes;
new client/server validation rejection;
new cross-field relation or type/range block;
new role/menu/page/API/action/record deny;
new module/capability/session/token/CSRF Gate;
new status/state/classification/ownership/approval/lock Gate;
newly hidden or disabled actions;
edit/delete/void/reopen/retry/reversal removal;
provider/sync/reference/audit state becoming a primary-operation prerequisite;
successful API result changing to an error;
broader rollout than the approved subject/surface.

These definitions prevent semantic evasion such as calling a restriction hardening, cleanup, contract alignment, or test correction.

5. Existing Security Preservation¶

The policy has two separate invariants:

existing current controls
= preserve by default

new or changed controls
= require exact user authorization

This prevents both unsafe directions:

an agent cannot add a new denial because it believes one is needed;
an agent cannot remove an existing denial merely to make a test or flow pass.

When current behavior is unknown, the correct outcome is read-only discovery and DECISION REQUIRED, not allow or deny by assumption.

6. Task Detail Correction¶

Every applicable Task now requires a dedicated Live Operation And Restriction Delta Contract containing:

exact current field optionality;
accepted empty/zero/unknown/draft behavior;
exact current UI/API access behavior;
exact current state/edit/delete/retry behavior;
restriction delta ledger;
prohibited inferred restrictions;
positive allow-path scenarios;
approved deny scenarios only when applicable;
rollback and deployment authorization;
independent claims.

The default ledger contains only:

RD-000 — no restriction delta; current behavior retained

This is intentionally explicit. Silence is not sufficient because silence previously allowed agents to invent policy.

7. Work Graph Correction¶

Restriction-sensitive Work Graph runs must now account for:

current allowed paths
current optional inputs
current known denies
unknown caller/access rows
proposed delta rows
deployment authorization

Required critical claims:

restriction.delta.none
or
restriction.delta.exactly_authorized

operational.allowed_paths.preserved

A fresh verifier must inspect the actual diff for validators, rejection paths, permission guards, status Gates, and blocking messages. The implementation author's tests and narrative are not sufficient.

8. P2-007 Correction¶

P2-007 is the highest-risk existing Task because it directly covers live tenants, roles, menus, pages, APIs, input minimums, and workflow acceptance.

The addendum makes the following authoritative interpretations:

Parent wording	Correct interpretation
expected allow/deny	document current evidence; do not choose policy
least required access	do not broaden as shortcut; do not narrow without approval
UI/API parity	preserve intended current operator path; do not make both sides equally denied
hard block for security/integrity	user decision required for a new block
unknown caller	no change; proposed deny stops
role/API matrix	read-only inventory until exact delta is approved

P2-007 remains on USER HOLD; the addendum does not activate it.

9. Deployment Correction¶

The following boundaries are now explicit:

feature/fix request
!= restriction authorization

restriction authorization
!= source implementation authorization

source implementation
!= qa push

qa push
!= master promotion

master promotion
!= Runtime/config/DB/provider effect

A general release request cannot carry an unlisted restriction delta. A restriction release must name the exact delta, candidate SHA, tenant/profile, role/action, allow-path evidence, rollback, and observation.

This review performs no deployment.

10. Validation Wiring¶

The existing local Task-profile validator is extended to verify that:

Appendix Q exists;
the canonical live-operation rule exists;
the Task restriction overlay exists;
the P2-007 addendum exists;
AGENTS references all mandatory owners;
the Task registry references the overlay;
the overlay references the P2-007 addendum and required section/claim names.

Focused tests include a missing-policy-wiring failure case.

These checks prove repository wiring only. They do not prove Runtime behavior or user acceptance.

11. Applied Repository Surfaces¶

Planned bounded owner set for this correction:

AGENTS.md
.agents/rules/LIVE_OPERATION_CONTINUITY.md
docs/requirements/CTC_PRODUCT_PLATFORM_AND_DOCUMENTATION_CONTEXT_APPENDIX_Q.md
docs/tasks/README.md
docs/tasks/RESTRICTION_DELTA_REQUIREMENTS.md
docs/tasks/P2-007/LIVE_OPERATION_RESTRICTION_PRESERVATION.md
.agents/skills/ctc-work-graph/bin/validate-task-profiles.mjs
.agents/skills/ctc-work-graph/tests/task-profile-validator.test.mjs
docs/research/agent-execution/2026-08-10/CTC_LIVE_OPERATION_RESTRICTION_POLICY_REVIEW.md

No application source, API route, permission row, menu, role, migration, config, account, provider, service, Wiki DB, or deployment surface is in scope.

12. Residual Limits¶

After this correction:

older individual Task files do not all physically duplicate the overlay;
they consume it through AGENTS and the Task registry;
exact current input/access behavior still requires activation-time source/environment evidence;
no current security/access policy is inferred from this documentation;
no Stage 4 operational Work Graph pilot is created by this policy update;
no Runtime or target-role verification is claimed;
no deployment is authorized.

The next restriction-sensitive implementation must demonstrate that the overlay is used in a real Task and that current allowed paths are preserved.

13. Final Review Questions¶

Before accepting any later restriction-sensitive result, ask:

What exact user request authorized the restriction?
What worked before?
Which tenant, role, page, API, action, field, or state changes?
Which current allowed paths remain available?
Were optional/draft inputs preserved?
Did the implementation add a hidden restriction outside the ledger?
Did tests invent policy or prove approved policy?
Did a fresh verifier inspect the actual diff?
Was deployment separately authorized?
Can the exact delta be rolled back without discarding unrelated work?

If question 1 has no exact answer, the correct restriction result is NOT IMPLEMENTED.

---¶

Source: docs/research/agent-execution/2026-08-10/CTC_LIVE_OPERATION_RESTRICTION_POLICY_REVIEW.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.