Use projects/chirality-app-dev as WORKING_ROOT, its AGENTS.md for repository-development constraints, and init/dev-loop-init-prompt.md → loop/LOOP_INIT.md for entry. instructions/AGENTS.md is the guidance shipped to App users; it has a different applicability from the repository-development entry. The source basis for implementation is the PRD, accepted decomposition and scope changes, live DepClosure pointer, relevant deliverable contracts, decisions, and actual brief. App project instructions · App loop

At this basis, the published App loop says “none selected for a successor undertaking.” Its revised procedure matches the shared graph, closeout and memory methods. Before using that revision, establish the receiving loop's accepted basis from its own records; the source notice does not repin its authority corpus or resume product development. Recover any continuing concordance program from its actual activation, graph, phase cursor, handoff and owner directions. Existing pins, pauses and packet-specific repair authority persist until their owning transition. App loop · App development-loop notice · Reconciliation contract

Before relying on, dispatching, promoting, or consuming an accepted dependency for an App deliverable, run APP-HOLD-1 for the exact target and act. The following is a template from the App working root; choose the actual permitted operation and declared entry path:

python3 execution/_Scripts/app_hold.py check \
  --operation <reliance|dispatch|checking-promotion|accepted-dependency-consumption> \
  --entry-path <actual-entry-path> --target <DEL-ID>

The pipe-separated operation field denotes alternatives, not a literal shell argument. A missing preflight, held target, malformed basis/admission, or register/scan disagreement blocks the act. Historical DEL-09-07 admissions are not current reusable exceptions. The check never authorizes an authority-corpus re-pin. APP-HOLD-1 rules · App hold tool

Source principally lives under frontend/src, frontend/electron, frontend/packages, and frontend/scripts; the frontend workspace contains its tests and build configuration. Current App and Runtime manifests require Node >=22.19.0; the older App build guide's >=20 statement is stale at this basis. Read the current executable manifest and disclose discrepancies rather than installing from an outdated prose requirement. App package manifest · Runtime package manifest · App build guide

The registered App checks include frontend-test, frontend-typecheck, frontend-build, frontend-premerge, harness-self-check, harness-pytest, and app-hold-integrity. Project instructions additionally specify their applicable closeout, product-source, UI, native-host, packaging, and corpus-reconciliation obligations. Stop the ordinary dev server before build/package/premerge operations. The registered premerge check owns a stub service and HARNESS_BASE_URL; calling its npm script alone does not supply that setup. App profile · App checks

npm test, npm run typecheck, and npm run build are declared in the frontend manifest; use them only as selected authorized checks. Packaging is separate: desktop:prepare prepares/builds inputs, while desktop:pack and desktop:dist consume prepared inputs and perform their declared verifiers. Their existence grants no signing, notarization, distribution, or release authority. Retained compatibility scripts do not establish another qualified MVP engine. Codex remains the App target, with application-owned Runtime hosting the stock Codex App Server under the current accepted boundaries. App package manifest · App development boundaries · Runtime PRD revision