Start implementation from the accepted objective, current candidate, explicit write fence, exclusions, and checking basis. Inspect the smallest coherent implementation and test surface. Make the change needed to establish the behavior, including source, tests, configuration, or documentation when their relationship requires it. Preserve unrelated user work. A local repair does not authorize unrelated dependency or public-contract changes, migrations, release, or operations excluded by its brief or method. Authorized registered setup may proceed within those boundaries. Bounded implementation · Chirality change conventions

Use tests to examine the requirement, not to invent it. Identify the expected result and its source. Protect adopted tolerances, oracles, limits, and checks when they conflict with implementation. A known failure disappears illegitimately if its criterion is removed or weakened. Diagnose the discrepancy, preserve the measured result, and bring a protected-criterion conflict to the owner with a recommendation. Hold the affected acceptance or merge while independent work proceeds. App review rules · Piping software checks

Select verification from the actual affected behavior and project requirements. The project-local software-workflow.json supplies registered command arrays, working directories, always-checks, and path mappings. The selector proposes affected checks; it does not execute them or prove coverage. Consider indirect consumers and mandatory project checks that path matching may not capture. An empty selection or exit-zero result supports no broader conclusion than the operation actually performed. Software profile contract

This copyable inspection example asks which checks the current App profile selects for a hypothetical project-relative source path. It changes no product files and does not run the selected checks:

REPO_ROOT="$(git rev-parse --show-toplevel)"
cd "$REPO_ROOT"
python3 tools/software_workflow/select_affected_checks.py \
  projects/chirality-app-dev/software-workflow.json frontend/src/example.ts

Replace the example with the complete actual changed-path list. The command interface was checked with --help for the inherited v2 operational source basis; its source bytes are unchanged in this edition's comparison. The check runner is a separate operation. The following is deliberately a template, not a command to execute unchanged:

python3 tools/software_workflow/run_registered_checks.py \
  <project/software-workflow.json> \
  --check <explicit-authorized-check-id> \
  --output <authorized-evidence-path.json>

Supply each authorized check explicitly; omitting --check causes the current runner to run all registered checks. The output path also needs authorization. The bounded implementation method prohibits unregistered install, release, network, and destructive commands. A missing prerequisite should return as a specific preparation need or revised assignment, not an improvised command outside that method. Registered runner · Implementation tool policy

A registered check may own a bounded service lifecycle. The runner can allocate a loopback port, start the service, wait for readiness, inject declared environment values, run the check, and shut down the service. Preserve the distinction between service setup failure, timeout, and a product check failure. An App premerge command run without its required service is not the registered check. Coordinate ordinary dev servers with build and premerge operations so shared output directories are not written concurrently. Software profile, managed service · App profile · App checks

Exercise the actual consumer route as soon as it becomes operable. For an interactive change, inspect resulting model, history, and persisted state as well as visible feedback. Relevant journeys can include editing, invalid input, cancellation, apply/reject, undo/redo, save/reopen, interruption, and recovery. For a service, examine the request, response, state changes, failure behavior, and subsequent consumer operation. Component tests and connected checks answer different questions. App development checks · Piping software checks

Use native application evidence for a native-host claim where the owning criterion requires it. Browser evidence can support browser behavior but cannot silently substitute. Agent-operated exercises can provide reproducible observations; they do not lift practitioner-usability holds or supply professional acceptance. If the host cannot run a required check, retain the exact command, reason, candidate, and outstanding verification. In App this is recorded as HOST_RERUN_REQUIRED; a missing profile binding is a different failure. App host-capability rule · Piping software checks

Evidence should make the observation reconstructible at the claimed scope. Identify inputs, candidate, relevant configuration, tool/environment versions, command or actions, expected outcome, observed outcome, exit status, and needed raw output. Retain non-secret bytes and a bounded rerun method where required. Record skipped, unavailable, interrupted, failed, and passed separately. Use one canonical copy with references from the graph or deliverable. Formatting a result does not upgrade its warrant. App evidence contract · Piping evidence contract

Review the complete frozen candidate independently before a mergeable slice integrates. The reviewer did not implement the change and receives the requirements, full diff, relevant evidence, and limits. App product source retains its explicit fresh read-only TASK + software-code-review path. Examine changes to tests and criteria as closely as production code. Repair actionable findings, preserve disagreements and their grounds, and backcheck the changed content and affected consequences. A review of an earlier revision does not cover later edits automatically. App review rules · Piping review rules · Software code review skill

Before Git closeout, inspect the receiving state, current diff, index, upstream changes, and owned file set. Recheck interactions introduced by integration. For sgttomas/chirality, standing owner authorization permits commit, push, PR creation/update, and merge within authorized scope once required CI and independent review cover the actual candidate with no unresolved blockers. Explicit holds and later owner directions prevail. Use configured identity and truthful attribution; do not imply personal owner review. This authority grants no product acceptance, release, or protection bypass. Root entry · PRD Root merge policy · Chirality change conventions