jungho-git/boundary

Boundary

• Shared examples and formatting reference: references/EXAMPLE.md.
• Keep new guidance, snippets, and edits aligned with that file.

---

Scope

Use this rule when:

• choosing which local files to read, search, edit, review, or validate
• generated, cached, temporary, vendor, log, build, or backup paths appear in search results
• deciding whether an artifact is source-of-truth or only an output
• an explicit user path points into an otherwise blocked area

Boundary control should reduce noise while preserving evidence needed for the user's actual task.

---

Decision Order

• Start from the user's explicit target and nearby repository metadata.
• Identify the canonical source before reading outputs or generated artifacts.
• Prefer source files, tests, migrations, schemas, manifests, lockfiles, configs, and maintained docs over outputs.
• Treat generated, cached, temporary, vendor, build, log, and backup paths as blocked by default.
• Read a blocked path only when it is the direct subject, no source alternative exists, or it is needed to verify an artifact contract.
• Edit a blocked path only when the project intentionally stores it as a maintained deliverable or the user explicitly asks for that artifact.
• State the exception when blocked-path evidence affects the final answer.

---

Source Classification

• Strong source: application source, tests, fixtures, migrations, schemas, mapper files, API contracts, scripts, package manifests, lockfiles, configs, templates, maintained docs, and checked-in examples.
• Conditional source: generated clients, generated types, snapshots, compiled assets, vendored patches, database dumps, exported reports, and build artifacts that the project explicitly treats as deliverables.
• Non-source by default: caches, temporary folders, logs, coverage, build output, dependency installs, editor history, backups, minified bundles, and runtime scratch files.
• If classification is unclear, inspect nearby config or docs first, then make the narrowest reasonable assumption.

---

Read Rules

• Do not use blocked paths as primary evidence when a source file exists.
• Do not expand exploration into blocked directories because a search result appears there.
• Read only the specific blocked file needed for the task when an exception applies.
• Prefer metadata or directory listing over full file reads when deciding whether a blocked artifact matters.
• Do not let duplicate generated files outvote source files during review or validation.

---

Edit Rules

• Do not edit generated or compiled output when the generator source can be edited instead.
• Do not edit installed dependencies, caches, logs, coverage output, or backups to solve source defects.
• If a generated artifact must be updated, update the source and run the generator when available.
• If the generator is unavailable and the artifact is a required deliverable, state that the edit is artifact-only.
• Keep blocked-path edits narrowly scoped and explicitly reported.

---

Validation Rules

• Validate source changes through source-level tests, type checks, parser checks, or generation commands when possible.
• Use generated artifacts for validation only to confirm generation output, packaging, snapshots, or deployed assets.
• Do not claim source behavior is verified because only a compiled bundle or log was inspected.
• When logs are the only failure evidence, pair them with source inspection before proposing code changes.

---

Boundaries

• Do not ignore explicit user scope.
• Do not treat broad blocked-path searches as repository understanding.
• Do not delete or rewrite generated artifacts unless the task requires it and the source/generator path is understood.
• Do not assume a checked-in artifact is disposable; classify it from project evidence first.