Skip to content

CTC Live Operation Continuity And Restriction Changes

  • Status: CANONICAL CURRENT AGENT INSTRUCTION
  • Owns: restriction classification and preservation of current accepted operator flows
  • Does not own: Product scope, current Runtime facts, Task status, deployment or effect authorization

1. Default

When the user did not request a restriction change:

RESTRICTION DELTA = NONE

Do not make an accepted operation fail, disappear, require more input, require another role, wait for another state or depend on an optional provider merely because it appears safer, cleaner or easier to test.

Preserve existing authentication, authorization, tenant isolation, validation and state controls. This rule neither narrows nor broadens access by assumption.

2. Classification

Use exactly one current classification:

NONE
USER_AUTHORIZED
DECISION_REQUIRED
  • NONE: no new required field, rejection, access gate, state gate or blocking prerequisite.
  • USER_AUTHORIZED: the current user request explicitly names the exact change. Record it and proceed without asking for the same confirmation again.
  • DECISION_REQUIRED: an agent proposes a restriction not contained in the request. Do not implement it. That decision blocks only that proposal; continue independent requested work.

Legacy spellings may be read during migration but new or reactivated work uses the canonical values.

3. Restriction-Sensitive Changes

Treat these as restrictions when they can reject or hide a previously accepted path:

  • field requiredness, accepted values and normalization;
  • role, menu, page, route, API, action or record access;
  • module, capability, entitlement or configuration gates;
  • status, approval, ownership or lock gates;
  • edit, delete, reopen, retry, correction or reversal availability;
  • provider, sync, audit, file or reference prerequisites;
  • user-visible blocking errors and rollout target.

Tests, schemas, types, security slogans and architectural preferences do not authorize a restriction.

4. Direct User Requests

An exact direct request to add, remove or change a restriction is authorization for that exact scope. Update the selected Task/manifest with the user request and affected subjects; do not reject it solely because an older default says NONE.

A direct request does not authorize unrelated restrictions, credentials, destructive data changes, provider calls or deployment.

5. Implementation Contract

For the in-scope flow record:

current positive path
requested behavior
restriction classification
new required fields
new validation/rejections
new access gates
new state gates
rollback/recovery
evidence

When classification is NONE, all four new ... lists are empty.

Verify the existing positive path before deny cases. Administrator success does not replace the operational role requested by the user. An optional post-write failure must not undo a successful primary result unless the user explicitly requested that transaction boundary.

6. Reporting

Report the exact delta and evidence. Do not use vague claims such as “hardened” or “least privilege applied.” A missing prerequisite is BLOCKED; an unexecuted scenario is NOT_RUN.

---

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