CTC Development And Documentation Standard

• Status: CURRENT LEGACY STANDARD / HISTORICAL PROGRAM REFERENCES
• Owns: development/document classes, metadata, naming, lifecycle/retention, creation/move review and high-level Legacy change/review standard; former P1–P12 vocabulary is retained as historical context
• Does not own: Product/System content, current Runtime facts, live Roadmap state, Request records/store, process/manual semantics, agent startup, Git/external effects or release authorization
• Update when: an approved development/document class, lifecycle, metadata, template or creation/move boundary changes
• Related sources: PRODUCT.md, DESIGN.md, ROADMAP.md, REQUEST_OPERATIONS.md, Agent workflow, Project Operations, and
• Approval: P1-001 D2=B; D1/D3~D12=A; P1-004 V1=B; V2~V6=A, 2026-07-30; distributed code-composition cleanup direction, 2026-08-02

Scope And Current Entry Points

This document preserves the document and change baseline for Legacy maintenance, and the basis of the earlier programme. The P1–P12 responsibility assignment, lanes and past candidates are history from the closed root programme and do not activate current work or decide New-System procedure.

New-System document placement and authority are in the documentation map; the development method is in the development guide; a task's request, state, verification and handoff follow the Task and Git. The phase order and exit conditions are owned by the New-System Roadmap. The material and consumers of the Legacy wiki are in the root Wiki guide; the authority of the New-System operator manual and the read-only development specifications is distinguished in the New-System Wiki guide.

Principles

1. Route a question to its document class before comparing authority.
2. One recurring question has one current owner.
3. A target is not implementation proof.
4. A current technical owner states verified fact only for its surface.
5. Research and evidence never own Product, Phase, Task or process status.
6. The root docs/ROADMAP.md program is CLOSED and owns only frozen P1–P12 history. new-system/docs/ROADMAP.md owns phase order and exit gates. The exact Task under new-system/docs/tasks/ and Git history own current scope, status, execution and handoff. new-system/docs/EXECUTION.md is a retired-ledger compatibility pointer, not a live owner.
7. A process contract owns behavior; a manual owns user procedure.
8. Process state, authority, exception, retry and recovery precede module and handler templates.
9. Git history is the default history store. A history pointer requires a proven consumer or unique navigation need and a removal condition.
10. No catalog, generated status, exact-text validator or template generator is part of this standard.
11. Code-composition cleanup follows the owning Product/platform/module/frontend/ performance Task. Do not recreate a cross-authority catch-all refactor Task.

Conflict Resolution

For the same question:

latest explicit user-approved decision in Context or final owner
-> matching document-class owner
-> verified source/environment fact for implementation questions
-> dated evidence
-> research
-> history

This is not a global override chain. Product target and Runtime fact answer different questions and cannot override each other.

When two current owners answer the same question, stop the affected integration, record the exact conflict, select or narrow one owner, update both references in one change and keep the issue OPEN-DECISION until approval.

Canonical Classes

Class	Single question	Canonical path	May own	Lifecycle / constraint
Repository entry	Where does a human start?	README.md	navigation only	CURRENT; no live status copy
Agent routing	What must an agent read/obey?	AGENTS.md, .agents/rules/**, .agents/skills/**	scoped agent instruction	CURRENT; no Product/Task status
Product	What Product, value, scope and gates are approved?	docs/PRODUCT.md	Product target and Stability criteria	CURRENT TARGET; no implementation proof
Target Design	What target authority/decomposition/invariant is approved?	docs/DESIGN.md	target System/Repository design	CURRENT TARGET; no Runtime proof
Runtime Architecture	How does verified Runtime currently work?	.agents/rules/ARCHITECTURE.md	current Runtime facts	CURRENT FACT; source/evidence scoped
Technical contract	What current API/DB/tenant/UI/integration rule applies?	.agents/rules/<SURFACE>.md	scoped current fact/contract	CURRENT FACT/CONTRACT
Development	How are Legacy development and documents governed?	docs/DEVELOPMENT.md	this Legacy standard	current Legacy rules; former program references are historical
Project Operations	How is approved repository/effect/release work performed?	.agents/rules/PROJECT_OPERATIONS.md	execution rules	CURRENT INSTRUCTION; cannot authorize scope
Roadmap	What happened to the root program?	docs/ROADMAP.md	P1–P12 closure and successor routing	CLOSED; no current activation
Task	What did a former root Task plan or verify?	docs/tasks/Pn-nnn.md	historical execution detail	frozen; current work follows new-system/docs/tasks/README.md
Request policy	What is a Request and how is it separated from Task/deploy?	docs/REQUEST_OPERATIONS.md	policy only	CURRENT POLICY; no live registry
Process	What behavior/state/authority/recovery is required?	docs/processes/PROCESS_CONTRACT_STANDARD.md, *_WORKFLOW.md, process-registry.yaml	schema, workflow behavior, navigation/lifecycle projection	DRAFT/REVIEWED/APPROVED/DEPRECATED; evidence proves promotion
Current System Wiki	What verified current system can a user operate and where does AI trace it?	DB T_WIKI_PAGE, presented at /operations-manual; internal map at docs/wiki/internal/PAGE_MAP.md	user-first current-system projection and slug-to-owner navigation	current page row; internal map links source/process owners; same-change update
Manual/SOP	How does a role perform and recover an operation?	DB T_WIKI_PAGE for user procedures; focused *_SOP.* only where provider evidence is unique	user guidance	DRAFT/APPROVED/DEPRECATED; same-change consumer migration
Research/observation	What was investigated or observed, where, when and with what limits?	docs/research/<topic>/<YYYY-MM-DD>/	dated research and observations	RESEARCH-INPUT; no current status
ADR	Why was one durable decision made?	docs/decisions/NNNN-<slug>.md	named decision/rationale	PROPOSED/ACCEPTED/SUPERSEDED/REJECTED
Runbook	How is an authorized operation performed and rolled back?	docs/runbooks/<NAME>_RUNBOOK.md	procedure only	DRAFT/CURRENT/SUPERSEDED; never authorization
Local review artifact	What Local proposal is awaiting integration?	owning Task/research path	proposal only	LOCAL PROPOSAL; no remote status/evidence
Minimum Verification Standard	What minimum changed-surface policy applies?	this file	approved verification policy	CURRENT STANDARD; advisory only

Document lifecycle, process maturity, Product outcome, Stability proof and Phase/Task status are independent. None proves another.

Existing root documents and assets are preserved after confirming their Legacy consumers and historical basis. The existence of existing docs/evidence/ or Wiki material is not by itself a basis for creating or deleting an authority. New New-System material is recorded at its owned location in that map. The root's past docs/tasks/Pn-nnn.md and Wiki asset paths are not reused as New-System authoring locations.

Shared Metadata

Use the smallest applicable current-owner header:

Status:
Owns:
Does not own:
Update when:
Related sources:

Add only when applicable:

Decision/approval:
Verified source/environment/date:
Runtime/script/operator consumers:
Supersedes:
Retention/removal condition:

Research/observation records use:

Classification: RESEARCH-INPUT | OBSERVED-FACT
Captured:
Source/revision:
Environment/tenant/role:
Method:
Limitations:
Mutation summary:
Retention/removal condition:

A Local proposal states LOCAL UNCOMMITTED REVIEW ARTIFACT, its remote source basis and that it is not authority, Roadmap status, completion or committed evidence.

Machine-readable metadata stays in its schema or linked owner. Binary evidence uses a nearby record; do not duplicate the binary to carry metadata.

Minimum Content By Class

Product

• purpose/customers, value/model, scope/non-goals;
• profile/module/configuration boundary;
• first slice and reference regression;
• Product/Stability gates and measures;
• deferred commitments and open decisions.

Target Or Current Technical Owner

• owned question and current-vs-target boundary;
• authority/invariants;
• dependencies/consumers;
• compatibility/migration;
• unknown/deferred commitment;
• update evidence.

Objective=Phase Roadmap

• North Star link;
• Phase necessity, baseline/unknown, target and in/out scope;
• must-preserve, entry/completion, benchmark/deferred feature;
• Task registry, Lane, parallel/dependency/final-writer boundary;
• review note and live-state change rule.

Task

• outcome and Product value;
• status source, Phase, Lane, parallelism and dependency;
• inputs, in/out scope and must-preserve;
• stages, deliverables, acceptance and verification;
• stop/rollback, evidence, handoff and completion review.

Request Policy

Definition, authority, current intake/channel boundary, Task/incident/deployment separation, prohibited assumptions and P3 open decisions. It does not define a record/store/API implementation.

Process

Former P1/P6/P5 responsibilities are historical. Current Legacy process contracts remain source-scoped; New-System process ownership follows its documentation map.

Current System Wiki

• user content: T_WIKI_PAGE.MARKDOWN, rendered at /operations-manual;
• repository navigation: docs/wiki/README.md;
• internal trace: exactly one curated SLUG entry in docs/wiki/internal/PAGE_MAP.md; after a Wiki slug rename, use its stable PAGE_SLUG association. Page-specific drafts otherwise match the lowercase form of exactly one registered route key in config/page_routes.php;
• technical and process facts remain in their existing owners; the internal map links them and does not copy or replace them;
• do not create docs/wiki/user/, a generated mirror, hidden Wiki metadata or a second writable authority.

Manual

Audience/role/access, menu/purpose, input/visible completion, steps/decisions, error/retry/correction/recovery, approved process link and last field/runtime verification limitations.

Research

Question/scope, sources/date/environment, method, observed facts, comparison, unknowns/limitations, proposals separated from facts, downstream owner and retention.

ADR

Status/date/owner, context/drivers, options, decision, consequences, rollback/supersession and implementation/evidence links.

Runbook

Purpose/authorization boundary, target/prerequisites, steps, readback/success, failure/stop, rollback/cleanup and evidence/escalation.

Task, Lane And Parallel Vocabulary

• Former Task ID: Pn-nnn; existing files are frozen reconstruction inputs.
• Current Task scope/status belongs to the exact New-System Task and Git, not the root Roadmap.
• Former Lane vocabulary: Cloud, Cloud RO, Local, Local RO, Local Field, Cloud Review, Cross-repo, Explicit activation.
• Parallel: possible, conditional, not possible.
• Parallel work requires independent read-only scope or truly disjoint authority. One final writer integrates shared owners.
• Different directories alone do not prove safe parallel writes.

Creation, Change And Move Gate

Before creating a current document, answer:

1. What single question does it own?
2. Why can no current owner answer it?
3. Who is the audience?
4. What class/lifecycle applies?
5. Who updates it and when?
6. Which Runtime/script/build/operator/external consumers exist?
7. Which inbound links exist?
8. Does it copy another owner?
9. Which Product/Phase/Task does it support?
10. What is the rollback, retention and removal condition?

Never create a second owner for the same question.

Historical rationale remains in the P1-002 responsibility overlay. Current scoped instructions govern changes: retain current discovery and consumer paths, do not create speculative or customer-specific source trees, and move only one proven owner in a bounded rollback unit.

The high-level change loop is:

PLAN (explore and define acceptance) -> EXECUTE -> VERIFY (review and report)

Review owner, consumer, current behavior, unknowns, Product value, scope, effects, acceptance, rollback, current-vs-target confusion and residual risk. Execution mechanics belong to Project Operations.

Before moving/deleting/renaming a document, Project Operations requires consumer search, same-change migration, actual-output verification, caller-zero and rollback. Copying content is not proof that the old source is removable.

Code Composition And Touched-Surface Guardrails

These rules apply inside the owning Task; they do not create a new Phase, catch-all cleanup Task, automatic validator or release Gate.

Authority distribution

The P2–P9 assignments below are a record of the closed programme. They are not reused as current execution authority or as a prerequisite gate.

• P2 may perform only the minimum extraction needed to deliver and verify the selected product workflow without increasing shared debt.
• P4 owns canonical tenant/deployment/profile/actor context, resolver precedence and tenant-scoped query/write/job/import/migration boundaries.
• P6 owns process state, record/mutation authority, invariant, retry, correction, reversal and recovery meaning before P5 templates consume it.
• P5 owns module/query responsibility inventory, public contracts, templates, reference conversion and bounded conversion/retirement waves.
• P7 owns page shell, browser lifecycle, jQuery/Bootstrap/inline/global frontend decomposition; it does not redefine backend query or process authority.
• P9 owns performance claims only after measurement.

Backend core and profile-extension naming

• Backend names describe the shared Product module and use case, not MK, CTC, a customer name or numeric tenant ID.
• Reuse one canonical backend command/query/function when behavior authority is shared. “Common” means one semantic owner; it does not authorize moving unrelated domain logic into a larger common_* helper.
• A profile-specific frontend page or adapter may retain profile terminology and composition, but it must call the canonical backend contract.
• Prefer profile/capability/configuration policy for variation. If a verified exception needs code, isolate it in a separately named module extension with a narrow input/output contract and explicit selector.
• Keep core invariants, transaction, repository and authoritative readback stable. An extension may add bounded behavior but cannot copy the core writer or bypass tenant, role, module, audit, retry or recovery contracts.
• Do not scaffold a generic plugin registry for hypothetical tenants. Add the smallest extension seam only with a real selected exception and a focused behavior-sensitive check.

User-input and validation policy

• Do not add a new client/UI validator, blocking validation state, or validation error message without a direct user request and confirmation. A test expectation must not be used to introduce one indirectly.
• Preserve server-side authorization, security, and concrete data-integrity boundaries in their current owner. Do not replace them with a speculative UI validator or expose a technical failure to the operator as an input error.
• Design for successful entry before error display: derive authoritative values, apply safe semantic defaults, auto-fill known values, constrain choices to valid options, and use contextual selection/autocomplete where practical.
• When an invalid value can be prevented safely, prevent its entry or keep the primary action unavailable with an inline, actionable prompt. Prefer a safe empty/draft/deferred path over forcing invented business data.
• Show an error only when it is unavoidable and the operator can take a concrete corrective action. The message must name that action; errors caused by a provider/system condition outside the operator's control must not be surfaced as a user validation failure.

Touched-surface rules

A new or changed surface should not introduce:

• new business-specific SQL or enrichment in a common orchestration helper;
• new ambient $GLOBALS or application/query-layer direct reads of $_GET, $_POST, $_SESSION or request headers;
• one string type or use-case registered across multiple owners;
• a new SELECT * where an explicit response/read-model contract is available;
• a runtime schema/config fallback without an owning environment, caller and removal condition;
• a duplicate tenant, process, transaction, module or effect authority;
• a customer-prefixed backend copy when a shared module/use-case owner exists;
• a numeric tenant branch where profile/capability/configuration or a bounded module extension is the approved behavior authority;
• a new framework, generated registry/catalog or validator as the price of a bounded cleanup.

When immediate product work cannot safely avoid compatibility, the owning Task records:

consumer/caller
required environment
current owner
why compatibility is still needed
removal condition and downstream handoff

The compatibility path remains explicit and temporary; recording it does not turn the Task into a broad cleanup authorization.

List/query composition target

The former P4/P6/P5 design sought one use-case owner sufficient to trace; these phase references do not activate current work:

module/use-case identity
-> explicit execution context
-> query/read-model definition
-> allowed filter/sort/date/pagination
-> count strategy
-> result enrichment/read projection
-> transport/legacy adapter
-> tests, callers and retirement condition

Do not introduce an ORM or generic query framework merely to satisfy this shape. The current PHP Runtime must be able to adopt it incrementally.

P5 module, application and adapter contract

The former P5 program recorded this incremental-PHP contract. Its retained Legacy constraints are applied through current scoped instructions, not by reactivating P5. Task files record execution and evidence; they do not create a second catalog, registry or framework.

Module and public contract

A touched module or use case records only the fields needed to trace the current contract:

moduleKey and useCaseId
owner and purpose
process, record, query/read-projection, transaction and effect authority
public commands, queries and events
pages, APIs, jobs and adapters
explicit tenant/profile/actor/module/capability context
allowed dependencies and prohibited dependency directions
current and minimum exposure
current callers, compatibility/rollback and removal condition
tests, documentation and operational evidence

Source/query authority may differ from the module that exposes a read projection. The projection owner must name that source authority instead of duplicating its SQL or business meaning. Profile and tenant configuration select shared contracts; they must not copy them.

Exposure is one of PUBLIC, ROUTE, CALLBACK, MODULE_INTERNAL, CLASS_PRIVATE or LOCAL. Current exposure remains until direct, include, route, callback, browser, job and external caller mechanisms establish a narrower minimum. Low fan-in and short bodies are review signals only, never caller-zero or deletion proof.

An abstraction is classified as JUSTIFIED, TEMPORARY_COMPATIBILITY, NOT_JUSTIFIED or UNKNOWN_HOLD. A retained layer must add a named semantic, public, transaction, effect, compatibility or test contract. Same-owner forwarding alone does not justify a new layer. Retirement requires surviving behavior, rollback and caller-zero evidence.

Command, query, transaction and effect contract

The minimum application path is:

transport adapter parses and validates the public request
-> explicit execution context and command/query data
-> one application handler owns one use case
-> repository/query definition owns SQL and persistence semantics
-> result/readback returns through the existing public response contract

• Application and repository code consume explicit data; they do not newly read request/session globals or re-resolve tenant/profile/module context.
• One query owner defines allowed filters, sort keys, date semantics, pagination, count strategy, result shape and enrichment/read projection. Request strings do not become SQL identifiers without an explicit allowlist.
• A command declares mutation, transaction boundary, idempotency/readback, correction/reversal and unknown-result reconciliation.
• The owning module retains transaction and effect authority. External provider or physical effects begin from a durable intent after the core transaction unless an exact approved contract requires otherwise.
• Provider/sync/audit/reference failure does not undo primary work unless that is an approved business invariant. Unknown effects use authoritative readback, not blind replay.
• Compatibility adapters name the caller, owner, rollback and removal condition. They do not gain business SQL, process state or filter/count/enrichment authority.

Transport, page, browser and provider/device adapters

• API adapters preserve route, method, moduleKey classification, authentication/authorization, standard envelope and error contract while delegating business work. Tenant module state controls menu/page exposure and does not by itself reject an authenticated API request.
• Page adapters preserve slug, menu/module/access mapping, direct-entry behavior and server-rendered include contract. Page shells do not own business SQL or process state.
• Browser adapters preserve mount/lifecycle, request parameters, response shape, loading/error behavior and legacy global/plugin compatibility. P7 owns broad frontend lifecycle modernization.
• Provider/device adapters declare capability, configuration and credential owner, timeout/retry/idempotency, authoritative readback/reconciliation and manual fallback. Provider/device implementation or live effect requires separate scope.

Current-source reference slice: completed transloads

This manifest describes baseline revision 3e59670381c7a43a3be1a810d0b0a2cc411c01b7 plus the P5 working candidate recorded at that time. This is historical evidence, not current source, deployed-Production or user-acceptance proof.

Contract	Current source
Identity and exposure owner	wms.inbound.completed-transloads; page/module owner wms.inbound; ROUTE API/page plus MODULE_INTERNAL query chain
Page entries	slug inbound-completed -> frontend/pages/system/TMS/transload/inbound-completed.php; also included by inbound-planning.php
Public API	authenticated GET /api/wms/inbound/transloads/completed, moduleKey=wms.inbound, standard data envelope
Query authority	tms.transload via wmsInboundQueryHandle -> transloadQueryHandle -> transload_completed_list
Context and source	explicit clientId; tenant-scoped T_TRANSLOAD, T_COMPANY, T_LOADING_PLANNER, T_USER read projection
Query behavior	date range, customer, loading type and keyword filters; fixed completion-time/ID descending order
Browser behavior	sends date/keyword/column filters and SORT; consumes items, derives total=rows.length, retains debug metadata
Transaction/effect	read-only; no transaction, provider or physical effect
Current compatibility debt	legacy TMS transport retains top-level completed-list filter normalization; WMS query handler forwards to TMS; old jTable SQL branch has unknown external consumers; browser SORT is currently ignored; no server pagination/count
Evidence boundary	P5-006 W1 Local API/legacy/browser parity is verified; Production and operational target-role acceptance remain NOT_RUN

P5-006 W1 keeps the legacy top-level parameter adapter because external caller-zero is not proven. The old jTable query branch, WMS forwarding layer, ignored browser SORT and lack of server pagination/count remain separate candidates; none may be removed or described as a performance defect without exact caller or P9 evidence.

Review and acceptance

For a touched hotspot, review whether responsibility and fan-out increased, stayed bounded or decreased. Acceptance uses focused behavior, caller and compatibility evidence selected by the owning Task. File length reduction alone is not completion, and source review alone is not Runtime or performance proof.

Lifecycle, Review And Retention

• Product/Design/Development: update on approved direction/boundary change; supersede in place.
• Runtime/technical owner: update with verified implementation change; remove only after successor and caller-zero.
• Root Roadmap/Tasks: preserve the closed program and unique decision/evidence links.
• Current New-System Roadmap and Tasks: update their distinct phase and execution owners through the current scoped workflow.
• Request policy: update on approved authority/channel/lifecycle decision; operational records follow their future store policy.
• Process: preserve stable IDs and deprecate with successor.
• Current System Wiki: save the affected current page in the same bounded delivery as user-visible behavior changes; update the internal map only when its slug-to-owner relationship changes; existing DB mutation logs and backups provide change trace and recovery.
• Manual: delete only after replacement, consumer migration and caller-zero.
• Research: retain unique detail/provenance; remove wrapper after absorption.
• Evidence: immutable except correction note; retain per decision/process need.
• ADR: retain accepted/superseded rationale; never reuse ID.
• Runbook: replace only with a verified successor.
• Local proposal: reconcile into a committed owner or delete after absorption.

Git history is the default historical store.

Templates

Files under docs/templates/ are optional copy examples, not authority or generated output. No template generator is approved.

Valid former plan.md Task fields were absorbed into task.md. The caller-zero former template was deleted under the approved P1-001 Stage 6 cleanup.

Minimum Verification Standard

Purpose: catch two repeated, cheap-to-detect mistakes on explicitly supplied repository files. It is a required completion check for every repository change; it is not a broad Harness, CI program, or Production release Gate:

1. unresolved conflict-marker-like lines;
2. basic syntax errors supported by tools already present in the repository environment.

The completing developer/Codex must invoke it once on every final changed regular file immediately before commit:

./scripts/verify-minimum.sh PATH...

Here, “manually” means the developer/Codex invokes the command; it does not mean optional or user-triggered. Rerun only when those file bytes change. The command reads current filesystem bytes only. It does not select a dirty tree, inspect a base range, prove staged or committed bytes, run from a hook, or authorize promotion/deployment.

Results And Exit

• unresolved marker or invalid supported syntax: FAIL / ADVISORY;
• missing supported parser/interpreter: BLOCKED / ADVISORY;
• unsupported type, missing/deleted/non-regular path, empty file or no supplied path: NOT_APPLICABLE;
• malformed/outside-repository input or script-internal failure: execution error and non-zero exit.

Advisory FAIL/BLOCKED results do not make the command exit non-zero and are never relabeled as PASS. If a user explicitly accepts proceeding after one, reuse the owning Task, review or release note to record the original result, check/path, reason, user instruction, scope and date. Do not add an override flag or exception registry.

Executable Checks

Input	Check
any non-empty regular supplied file	conflict-marker-like <<<<<<<, |||||||, >>>>>>> lines; bare ======= is intentionally ignored
.php	Local php -l
.js, .mjs, .cjs	Local node --check
.json	Node JSON.parse
recognized Bash/sh shebang	declared bash -n or sh -n
TS/TSX/SQL/CSS/YAML, no-shebang shell and other types	NOT_APPLICABLE; select a Task-specific command when needed

Git is used only to resolve the repository root and reject outside-repository paths. The script has no DB, provider, browser, service, credential, Git-write, commit, promotion or deployment path.

Marker detection is deliberately lexical. An intentional literal line matching one of the three forms can produce an advisory FAIL; narrow or remove the check under the rule below instead of adding a document parser or allowlist.

Complexity And Removal

Keep one scripts/verify-minimum.sh and no added dependency, config, allowlist, schema, generated status or backlog. If a valid input false positive cannot be fixed by narrowing the small parser/scope, or a check no longer proves its named failure mode, narrow or remove it during a later user review. Existing focused tests and runbooks remain separately selected tools under Project Operations.

Full Runtime Test

This section covers Legacy runtime verification. New-System verification follows its test guide.

Every change to Legacy logic runs the full runtime test below on Local. It does not apply to changes limited to documents, comments or formatting. The purpose is not to satisfy a test count but to confirm that the business processes a real user repeats actually complete without interruption, per user and per tenant. High-frequency processes observed in production logs are linked to an executable replay suite, and an item that is not linked is left as NOT_RUN or BLOCKED with its reason.

node scripts/run_full_runtime_test.js

The runner's first step, runtime-log-coverage-inventory, safely aggregates user, tenant, screen, API and HTTP failures from the log snapshots kept in the repository. This result is

LOG_OBSERVED_NOT_REPLAYED and does not mean a successful reproduction of user work. A real Production log readback and a Local runtime replay are reported as separate kinds of evidence.

• Client 1: verify the Office, Loader, Yard, Driver and Warehouse/Billing work selected from production logs with real browser input, the full set of menus visible to each role, authoritative DB readback, and cleanup.

• Client 2: there are no production logs, so log in through login.php with a temporary per-role local account, open every menu shown to each role in the real runtime, and verify read/refresh behaviour. Save and state transitions for Commercial, Booking, Inbound, Outbound, Inventory, Scale, Allocation, Brokerage and Cost/Packing rates are entered, read back and cleaned up separately in the fixture workflow of the same group. The shared KJView configuration is also checked for read/create/edit/delete entry on every runnable screen.

• If the Email, Telegram or QuickBooks modules are enabled on the target tenant, that runtime test fails in order to block external effects. No separate environment block is created.

• Provider effects, migration/backfill/repair, data import, remaining documents and manual UAT, and separate contract/unit checks are not part of the automatic runtime group; the reason is recorded in the summary as NOT_RUN. Safe Local core workflow UAT is included in the runner.

• A smoke test with no Local schema dependency records its result as BLOCKED and is not treated as a passing test. If even one BLOCKED remains after every runnable suite passes, the runner returns BLOCKED with exit code 2.

This test is Local runtime evidence. Its results are used only to analyse and record the regressions, environment and fixture state it found. It is not a gate that automatically approves or blocks a commit, a qa/master merge, or an operational deployment. A deployment decision is made by separate user approval, review of the exact release candidate, and the verification selected for that deployment scope.

A test failure or NOT_RUN records its cause and the affected scope clearly. A failure is not used as a reason to add a validator, an authority restriction or a business block that the user did not ask for, and it is not declared a deployment block.

Source: docs/DEVELOPMENT.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged. A user instruction quoted inside the text is kept in its original language.

In this section

Document	Contents
standard	CTC Development And Documentation Standard
test-guide	Test And Script Guide