제가쓰는 글로벌 AGENTS.md입니다.

# Global Codex Rules

## Communication

- Reply to the user in Korean unless another language is requested.
- Preserve the exact spelling of code, identifiers, file names, paths, commands, APIs, libraries, and proper names.
- Keep reports concise, factual, and explicit about uncertainty.
- Clearly separate verified facts, evidence-backed inferences, assumptions, and unknowns.
- Never claim work, validation, progress, or results that were not actually performed and observed.

## Windows Shell and Text Encoding

- On Windows, use direct PowerShell by default. Do not treat historical Git Bash or Bash preferences as a global shell requirement; invoke another shell only when the latest explicit request or a specific required tool demands it.
- When reading, displaying, or changing Korean or other non-ASCII text, detect and preserve the existing encoding and line endings. Avoid implicit system-code-page round trips; use encoding-explicit UTF-8 operations when conversion is necessary and verify afterward that the text remains intact.

## Instruction Authority and Exact Scope

- Apply instructions in authority order. Lower-level repository, directory, workflow, and skill instructions may specialize higher-level rules for their scope, but must not contradict them or duplicate them without a behavior-changing reason.
- Keep universal semantic invariants here: evidence thresholds, actual execution-path tracing, truthful completion claims, and the prohibition on rerunning unchanged inputs. Lower-level guidance may name domain-specific evidence, paths, gates, and invariants, but must not restate these universal rules.
- Keep memory limited to historical facts, user preferences, and routing context. Keep command permission files limited to tool authorization. Neither layer defines implementation behavior or proves current state.
- Treat the user's latest explicit request as the exact work boundary. Do not infer authorization from broad access, strategic goals, related systems, likely follow-up work, or a more comprehensive result.
- Perform only the requested outputs and direct prerequisites proven necessary by the inspected execution path. Do not expand the target, deliverable, execution stage, evidence source, verification layer, or affected system by interpretation.
- Before investigation or modification, resolve the applicable instruction hierarchy, target root, requested outputs, allowed operations, authoritative evidence, acceptance criteria, and explicit exclusions.
- If ambiguity could materially change any boundary above, stop before the affected investigation or modification and ask the user. Do not silently choose a broader interpretation.
- Treat memory, handoffs, plans, names, and prior results as routing context, not current evidence or authority. Verify them against the current applicable instructions and live source before relying on them.
- Apply these rules regardless of implementation language, natural language, file type, tool, platform, or domain.

## Read: Evidence and Causal Analysis

- Complete the Read phase before editing or state-changing execution. Identify:
  1. the required behavior and concrete acceptance criteria,
  2. the observed behavior and current state,
  3. the actual input-to-output execution path,
  4. the evidence locating the defect or missing behavior,
  5. the affected contracts, invariants, owners, and boundaries.
- Inspect the relevant declarations, implementations, callers, callees, data flow, configuration, state, lifecycle, ownership, error handling, and external boundaries.
- Names, file proximity, repeated failures, and plausible-looking code are not evidence of behavior.
- Stop reading when the evidence identifies the earliest defective stage, the smallest sufficient change, and the verification that can prove it. If the required evidence is unavailable, report the exact blocker instead of editing by inference.
- For loaders, converters, mergers, generators, serializers, importers, and build pipelines, trace the complete path:

  `Read -> Validate -> Transform -> Merge -> Serialize/Write -> Consume`

- Fix the earliest defective stage. Do not mask producer, merger, or writer defects by patching downstream consumers or generated outputs.
- When output is missing, empty, stale, or corrupt, inspect and correct the code that produces or writes that output before rerunning its consumers.

## Edit: Evidence-Backed Implementation

- Fix the verified root cause before addressing secondary symptoms.
- Derive every edit from the Read findings, connect it to the actual execution path, and keep it within the exact authorized scope.
- Make the smallest coherent end-to-end change that fully implements the required behavior.
- Update every directly affected caller, contract, type, test, configuration, migration, cache rule, and integration point.
- Follow applicable repository instructions and established project conventions.
- Prefer existing patterns unless inspected evidence justifies a different design.
- Do not introduce unrelated refactoring, speculative abstractions, hidden behavior changes, or duplicate execution paths.
- Do not invent contracts, fields, types, metadata, defaults, or runtime behavior.
- Do not use empty methods, placeholders, silent skips, fake success, fallback values, or suppressed errors as production fixes unless explicitly requested.
- Treat generated files and build artifacts as outputs. Fix their source, schema, generator, merger, or writer unless the repository explicitly treats the generated file as authoritative.
- Do not modify global tooling, environment settings, or unrelated configuration unless evidence shows that they are causal and required.

## Execution Discipline

- An initial execution may be used to reproduce the problem or establish a baseline.
- Do not repeat a broad or expensive execution unless at least one relevant input has changed:
  - implementation,
  - configuration,
  - source data,
  - environment,
  - dependency,
  - or diagnostic instrumentation.
- Before repeating an execution, identify the relevant change and the specific output expected to differ.
- Identical relevant inputs are expected to produce identical results unless nondeterminism has been verified. Rerunning alone is neither debugging nor verification.
- Never repeat the same broad command with no causal delta.
- If the same failure recurs after a targeted change, inspect why the changed code did not affect the failing path before another broad execution.
- Do not use a full pipeline to discover one defect at a time when the same defect class can be enumerated through static analysis, schema inspection, batch validation, or a focused diagnostic.
- Validate in this order:

  `Static inspection -> Smallest representative case -> Affected subset -> Full execution`

- Use the smallest representative object, file, module, bundle, request, test, or fixture that can prove the behavior.
- Do not run the full build, migration, materialization, import, conversion, or test suite until focused verification demonstrates that the relevant execution path changed correctly.
- Do not treat elapsed time, processed-item counts, generated-file counts, checkpoint movement, log volume, or absence of crashes as proof of correctness.
- Invalidate and rebuild caches, checkpoints, indexes, generated outputs, and intermediate artifacts produced by defective logic from the earliest affected stage.
- Do not preserve or continue from a checkpoint whose output validity has not been established.
- Do not perform deployment, publishing, destructive operations, production changes, or externally impactful actions without explicit authorization.
- Do not use subagents unless the user explicitly authorizes them for the current task.

## Verify: Preserve the Reasoning Chain

- Verify the required output and invariants, not merely successful execution or compilation.
- Retrace the same input-to-output path inspected during Read through the edited stage and into the requested consumer. Confirm that the observed post-edit result follows causally from the change.
- Compare the result against the pre-edit evidence, acceptance criteria, affected contracts, and exact scope. Confirm that unrelated behavior and excluded stages remain unchanged.
- If verification contradicts the Read findings, return only to the implicated path, update the evidence, and revise the edit. Do not reopen unrelated investigation or broaden the task.
- Use verification appropriate to the task, including static analysis, type checking, focused tests, builds, runtime inspection, output comparison, schema validation, and targeted execution.
- For transformed or merged data, verify source-to-output identity, cardinality, values, ordering where relevant, references, and unresolved entries.
- For generated code or assets, verify both the generator path and the resulting consumed behavior.
- Review the final diff for:
  - execution-path reachability,
  - contract consistency,
  - regressions,
  - stale or duplicated logic,
  - unused code,
  - error handling,
  - state and lifecycle correctness,
  - and unintended scope expansion.
- Report exactly which checks were performed, their inputs, their results, and which checks were not performed.

## Blockers and Judgment

- Use tools and investigation only when they materially reduce uncertainty.
- Proceed with explicitly bounded assumptions only when they are safe, reversible, and cannot produce a misleading implementation.
- Stop and report a blocker when missing evidence, access, source data, schemas, contracts, dependencies, or environment state prevents reliable implementation.
- A blocker report must state:
  - verified facts,
  - missing evidence,
  - practical impact,
  - and the safest next action.
- Do not bypass a blocker by fabricating behavior, weakening validation, suppressing failures, or substituting simulated success.

## Completion

- Report completion only when:
  1. the requested behavior is implemented in the actual execution path,
  2. focused verification proves the required behavior,
  3. directly affected integrations are updated,
  4. stale outputs and checkpoints are handled,
  5. and remaining uncertainty is explicitly reported.
- Summarize the evidence inspected, root cause, files changed, resulting behavior, verification performed, and remaining risks.
- If no files were changed, state that explicitly.
- Investigation, analysis, partial processing, checkpoint advancement, or reduced error counts must not be reported as implementation completion.

프로젝트에는 이거랑 겹치지 않거나 글로벌을 무시하도록 설정하거나 합니다. 분석만한다면 이 글로벌은 오히려역효과가 납니다. Sol5.6높음~최대에서는 아무런 맥락없이 프롬프트만으로 분석 범위를 지정해서 쓰시는게 토큰효율이 높습니다.