# Project instructions

## Scope and evidence

- Carry the current task through necessary investigation, implementation, verification, and review within its authorization. Preserve unrelated changes and explicit approval requirements. Ask early about decisions that materially change the objective; complete authorized preparation before seeking approval for the dependent action.
- Use code, configuration, and command output to establish current behavior. Use accepted specifications and decisions to establish intended behavior; report consequential disagreements.
- Confirm the relevant package manager, runtime, build scripts, and file ownership from this repository before choosing tools.
- Before code or Git operations, confirm the selected repository and its applicable instructions; when Git exists, check its root, branch, and dirty changes. Preserve user edits and existing worktrees. Records can be used without Git; do not initialize it merely to keep records.
- In an AAPB multi-repository workspace, shared records bind only explicitly registered members. Identify the current member or select a registered repository before code operations. At an ambiguous workspace root, resolve the target first; discovery candidates, siblings, and links are not registration or permission for bulk Git actions.
- Start with relevant paths, symbols, and filtered records. Expand exploration when missing evidence or affected dependencies justify it; batch independent reads and retrieve missing portions of truncated output.

## Architecture and changes

- Follow the project's accepted module boundaries and public contracts. A framework name does not select an architecture.
- When no architecture is documented, inspect the current structure and dependencies. For new work, choose a proportionate structure within the authorized scope and record decisions that later work must preserve.
- Before changing a boundary, identify affected callers, data ownership, compatibility, and verification. Keep temporary exceptions and their removal conditions explicit.
- Keep architectural detail in the project's existing specification or decision document. Link it here only when that document exists; do not duplicate the whole design in root instructions.
- Use the existing record entrypoint, such as CURRENT.md, to find the active objective, evidence, and next action. Read relevant links rather than every historical record.

## Records and collaboration

- Record meaningful milestones, decisions, important findings, blockers, and handoffs in the existing project records. Routine edits and every response do not require a new log.
- Keep CURRENT.md short and actionable. Keep current reusable rules, terms, and contracts in topic knowledge with applicable repositories, sources, confirmation dates, and confirmed or assumed status. Keep the background, reasoning, changes, exact verification, and remaining work in detailed dated worklogs; use monthly folders for new logs where the project follows that layout.
- Preserve existing records, local-only rules, and ownership. Link older member-local records as separate sources; do not move them or promote historical claims to current facts automatically. Global references are optional task-relevant material, not a mandatory reading chain.
- Give independent contributors bounded ownership and evidence. Keep one owner for shared current-state documents and separate draft files for parallel record work. Review a DRAFT's source paths, numbers, commands, URLs, decisions, and unknowns before incorporating it. Role instructions do not enforce a filesystem boundary.

## Verification and delivery

- Run the project's required checks and verification appropriate to the changed behavior. Distinguish static checks, fixtures, and actual application or device execution.
- Reuse passing results only when relevant inputs and execution conditions are unchanged and required gates allow reuse. Repeat or broaden verification for new changes, failures, or unresolved concerns. Changed executable examples and configuration contracts still need appropriate checks.
- Preserve exact commands, results, and remaining limitations where the project keeps evidence. Update stale current-state notes without rewriting history as current fact.
- Follow the project's Git and publication conventions within the user's authorization. Inspect staged changes and keep local-only or sensitive material out of public artifacts.