llm-wiki/rules/advisory-depth.md

Advisory Depth Rule

This rule defines how deep an analysis, recommendation, brainstorm, concept explanation, or plan critique must go before the agent sends a response. It applies to:

• Multi-file wiki reports (research-lane, link-verifier, adversarial-reviewer).
• Direct-response answers when the controller did not dispatch a subagent.
• Brainstorming and design conversations about wiki structure, document policy, taxonomy decisions.
• Concept explanations and "explain X" questions (especially for wiki/concepts/ extraction candidates).
• Plan gap reviews for wiki promotion pipelines (/ingest, /projectize, /interviewize, /blogify).
• Single-finding recommendations inside any of the above.

Wiki scope: 본 rule은 LLM Wiki 문서 작업의 자문 깊이를 강제한다. 코드(Java/CA) 자문의 동일 rule은 ca-tmpl .agents/plugins/ca-superpowers/rules/advisory-depth.md 가 처리한다 — 7 Contracts 의 골격은 동일하나 본 rule 의 예시·검증 명령·외부 인용 표준이 wiki 컨텍스트로 채워져 있다.

The user does not use this CLI to hear "this looks fine" or "this is a good idea". They use it for practical engineering advice they could not produce alone. Shallow advice is a failure even when the facts are correct.

Core Contracts

The agent must satisfy all four contracts below on any qualifying response.

Contract 1 — Goal → Assumption → Problem → Action Chain

Every finding, recommendation, or critique must be expressed as a causal chain with explicit real-world assumptions between the source text and the critique. The chain has seven required fields. None can be omitted.

- **원래 목표 / Original goal:**
  - 인용 / Verbatim quote: "<exact text, byte-for-byte from source>"
  - 위치 / Source location: `<path>:<line>` (or `<path>:<startLine>-<endLine>` for ranges)
  - 해석 / Interpretation: <agent's one-line restatement of what the quoted text intends>

- **현재 상태 / Current state:**
  - 인용 / Verbatim quote: "<exact text, byte-for-byte from source>"
  - 위치 / Source location: `<path>:<line>`
  - 또는 / Or: "해당 라인 없음 — 명세에 명시되지 않음" (only when the gap is the absence itself)

- **실무 가정 / Real-world assumptions (NEW, REQUIRED):**
  명시적 가정이 없으면 비판은 "에이전트가 상상한 구현"에 대한 비판이 되어 신뢰성을 잃는다.
  최소 1개, 일반적으로 2~3개의 명시적 가정을 나열한다.

  1. **가정 A:** <e.g., "implementation will be synchronous", "production scale > 1000 RPS", "team is using Kubernetes", "this branch will be implemented as-written">
     - **무효 조건 / Falsifies if:** <under what concrete condition this assumption is false>
     - **검증 방법 / How user can verify in their context:** <a specific check the user can run>
  2. **가정 B:** ...
  3. **가정 C:** ...

- **간극 / Gap (given the assumptions hold):**
  - **구체적 실패 모드 / Concrete failure mode:** <X 상황에서 Y가 발생하여 Z가 깨진다>
  - **재현 조건 / Reproduction condition:** <the trigger that actually exposes this in practice>
  - **이 finding이 무효화되는 시나리오 / When this finding doesn't apply:** <if assumption A or B is false, this gap disappears — be explicit about which assumption is load-bearing>

- **필요 조치 / Required action:** <the specific action that closes the gap>

- **조치 근거 / Why this action:** <why this specific action (not a generic one) is correct here, given the stated assumptions>

- **대안 / Alternatives considered:** 3~5 enumerated per Contract 2.

- **반대 논거 / Counterarguments (NEW, REQUIRED — minimum 1, typical 2~3):**
  이 권고를 적용하지 말아야 하는 시나리오, 또는 이 비판이 과장된 케이스를 명시한다.
  자기 권고에 대한 self-critique이며, falsification 가능성을 더 폭넓게 확보하는 단계다.

  1. **반대 A:** <이 권고가 틀릴 수 있는 시나리오, 또는 권고 비용이 효익을 초과하는 케이스>
     - **반대 근거:** <왜 이 시나리오에서는 권고가 부적절한가>
     - **사용자가 자기 환경에서 이 반대를 검증하는 방법:** <한 줄 체크>
  2. **반대 B:** <또 다른 falsification 시나리오>
  3. **반대 C:** ...

  반대 논거가 0개라면 finding은 자동 `BLOCKED`. 자기 권고에 반대할 시나리오를 단 하나도 떠올리지 못한다면, 그 권고는 충분히 검증되지 않은 것이다.

A finding without a cited Original goal (verbatim + line) is INFERENCE and must be labeled as such. A finding without a concrete failure mode in Gap is opinion, not advice. A finding without explicit Real-world assumptions is forbidden — the agent must surface the implementation, scale, or context assumption that turns the spec text into a critique-worthy situation, so the user can immediately tell whether the assumption applies to their reality.

Bare findings like "성능이 떨어질 수 있다" or "고려가 필요하다" are forbidden. They must be expanded into a Gap with a named failure mode (for example, "스레드 풀 200 큐 + AbortPolicy → 큐 포화 시 RejectedExecutionException → outbox publish 손실").

Why Assumption Surfacing matters

When the source text is ambiguous, in-progress (e.g., "검토", "TBD"), or stated at one level (e.g., "decision" vs. "implementation note"), the agent often imagines the worst-case implementation and critiques that. The critique then targets an imagined implementation, not the actual spec.

Examples of past failures this rule fixes:

• Spec says "NTP drift > 5초 시 readiness fail 검토" (line 116). Agent imagines "synchronous NTP query inside the readiness probe" and critiques DoS risk.

  • Without assumption surfacing: the critique sounds authoritative but targets an imagined naive implementation.
  • With assumption surfacing: the agent must write "가정: 검토 단계에서 동기 호출로 구현될 것". The user immediately sees: "no, my plan is async — this critique doesn't apply" or "yes, I had not thought about sync vs async — this critique stands".

• Spec says "management port 9001 분리" and does not specify SecurityFilterChain. Agent imagines "no filter chain configured, exposed to internet".

  • Without assumption surfacing: "9001 포트가 무방비로 노출됨" — overconfident.
  • With assumption surfacing: "가정: 사용자가 management context를 위한 별도 SecurityFilterChain을 아직 구성하지 않았음". User: "아, 나 이미 구성했어" → critique no longer applies, no false alarm.

The rule is not to weaken critiques — it is to make critiques falsifiable. A critique whose assumption is wrong should be visibly rejectable in 5 seconds, not waste the user's time chasing a non-existent problem.

Contract 2 — Decision-Relevant Option Coverage

When the user mentions any ordering, comparison, design choice, or "how should I do X", the agent must cover the decision-relevant option space, not only the option the user happens to have named. Factorial permutations that are equivalent under the same dependency constraints are not separate options.

Concrete rule of thumb:

• If the user names 1 ordering of N items, build the dependency DAG first. Identify blocking edges, reorderable groups, parallel groups, and skippable steps; compare only materially distinct topological schedules. Do not enumerate all N! permutations.
• If the user names 1 design approach, enumerate at least the canonical alternatives (typically 3–5).
• If the user asks "which library", enumerate the realistic candidates with their distinct trade-offs.
• If the user describes a workflow with N steps, list which steps can be reordered, which can be parallelized, which can be skipped, and which are blocking.

For each option in the enumeration, the response provides:

- **케이스 / Case:** <one-line label>
- **적용 상황 / When it fits:** <the situations where this option is the right answer>
- **고려사항 / Considerations:** <what must be true / what must be watched>
- **장점 / Pros:** <concrete, not vague>
- **단점 / Cons:** <concrete, not vague>
- **비교 / Compared to others:** <how this differs from the other options in the same enumeration>

After enumerating, the agent provides a conditional recommendation, not a flat "use X". The form is:

- If <situation A> → use <option α>, because <reason>.
- If <situation B> → use <option β>, because <reason>.
- If <situation C> → use <option γ>, because <reason>.

Flat recommendations like "X를 추천합니다" are insufficient. The agent always ties recommendations to situations.

Contract 3 — Plan Gap Detection

When the user asks the agent to review, critique, or extend a plan document, the agent must explicitly identify:

1. Tasks that should be in the plan but are not. For each, give:
   • Why it should be there (tied to the spec or original goal).
   • Where it should slot in the order (before / after which existing step).
   • What breaks if it is omitted.
2. Tasks that are in the plan but should not be. For each, give the reason for removal and the impact.
3. Tasks whose ordering is wrong. For each, give the corrected ordering and why.
4. Implicit assumptions in the plan. Surface them as explicit prerequisites.

A plan review that returns only "the plan looks good" is treated as BLOCKED. The agent must surface gaps or explicitly declare "no gaps found, all N tasks needed match the spec" with the matrix of plan-task → spec-section to prove it.

Contract 4 — Direct-Response Template

When the controller answers a non-trivial advisory request directly (no subagent dispatch), the response uses a structured shape. The template scales with question size; only sections that materially help the decision are included.

## 1. 질문 이해 / Question understood
- <한 줄 요약>
- 함의된 목표 / Implied goal: <what the user is actually trying to achieve>
- 함의된 제약 / Implied constraints: <budgets, deadlines, stack, scale; pulled from project context or asked if missing>

## 2. 경우의 수 / Option space
- <Option 1>
- <Option 2>
- <Option 3>
- ... (exhaustive per Contract 2)

## 3. 각 경우 분석 / Per-option analysis
### Case 1: <label>
- 적용 상황 / When it fits: ...
- 고려사항 / Considerations: ...
- 장점 / Pros: ...
- 단점 / Cons: ...
### Case 2: ...

## 4. 비교 표 / Comparison matrix
| Option | 적합 상황 | 주요 장점 | 주요 단점 | 비고 |
| --- | --- | --- | --- | --- |

(Required when there are 3+ options. Optional below that.)

## 5. 권고 / Conditional recommendation
- If <situation A> → <option α>, because ...
- If <situation B> → <option β>, because ...
(Flat "추천: X" is forbidden.)

## 6. 다음 결정 / Next decisions
- What the user must decide before the next step
- What information is still missing
- What questions the agent has for the user

For trivial single-fact questions (for example "이 메서드는 어디 있나요?"), answer with the fact and file:line citation only. Do not emit empty §2~§6 or N/A placeholders.

Contract 5 — Citation Discipline

Every claim that names a specific number, setting, behavior, decision, or quotation must be backed by verbatim quote + clickable file:line reference. This applies to:

• §1 Executive Summary claims
• §2 Evidence Matrix "Extracted facts" column
• §4 Per-File Findings (every field that references the spec)
• §5 Priority Recommendations "근거 파일:라인" column
• Direct-response answers that reference any file

Verbatim quote rules

• Byte-for-byte copy from source. No paraphrasing, no normalization, no translation in the quote itself.
• If the quote is too long to embed inline (>200 chars), use elided form: "<beginning 60 chars>" [...] "<end 60 chars>" with the [...] marker explicit.
• If quoting Korean text from a source, keep it Korean. If quoting English, keep it English. Mixed-language sources are quoted as-is.
• The quote must contain the specific content that supports the claim. Quoting a tangential line and then drawing an unrelated conclusion is FILENAME_INFERENCE adjacent and counts as a citation failure.

Source link rules

• Format: path/to/file.md:LINE for a single line, path/to/file.md:START-END for a range.
• Paths are relative to the workspace root, not absolute (/home/donghyeon/... paths are forbidden in citations).
• IDE-clickable: file:line is the universal format that opens directly to the cited line in VS Code, IntelliJ, terminal grep results, GitHub, and most code review tools.
• For sources outside the workspace (e.g., external docs the user pointed to), still use file:line and include the absolute path in a separate ## Source roots block at the top of the report.

Banned citation patterns

Pattern	Why it fails	Replacement
근거: <file:line> with no quote	User cannot tell if the cited line actually says what the agent claims	Always include verbatim quote alongside the line reference
(L67) style citations without the file path	Ambiguous when multiple files are discussed	Always include path: feature-X.md:67
Paraphrased "quote" rewritten in the agent's own words	Looks authoritative but is fabrication	Copy exact bytes from source. If clarity needed, add 해석: field separately
*근거: 위 문서 본문* / vague references	Untraceable; impossible to verify	Specific file:line + verbatim quote
Quoting line N when the claim is about line M	Misdirection; the cited line doesn't actually support the claim	Quote the actual supporting line, or label as INFERENCE
Citing a non-existent line	Pure fabrication	Verify the line exists before citing

Pre-send check (citation-specific)

송신 직전, 에이전트는 다음을 자기 draft에 대해 점검한다. 하나라도 실패하면 draft BLOCKED.

1. 모든 구체적 사실 주장에 대해 verbatim quote가 들어 있는가?
2. 모든 verbatim quote에 대해 <path>:<line> 형식의 위치 표기가 있는가?
3. 인용된 텍스트가 실제로 그 file:line에 존재하는가? (인용을 실행 가능한 grep 명령으로 검증할 수 있어야 한다)
4. 인용된 텍스트가 실제로 주장의 근거를 제공하는가? (탄젠셜한 라인 인용 금지)
5. 절대 경로 (/home/...) 가 아닌 워크스페이스 상대 경로인가?
6. 외부 디렉토리를 참조한 경우 §0 Source roots 블록에 절대 경로가 명시되었는가?

If a planned claim cannot be supported by a verbatim quote, the claim is removed or relabeled INFERENCE with an explicit note that no direct quote backs it.

Contract 6 — Proof Manifest Verification

모든 verbatim quote는 proof-request/v1에 (finding.id, finding.role)과 함께 넣고 proof_runner.py로 검증한다. 신규 run의 검증 SSOT는 inline shell transcript가 아니라 proof-manifest/v1이다. runner는 source 전체 SHA-256, line range, exact UTF-8 bytes와 finding-role 유일성을 확인한다.

source는 namespace를 명시한다.

• namespace: repo — --repo-root 아래의 저장소 자료
• namespace: run — --run-root 아래의 격리된 fetch·staging 자료

두 namespace 모두 상대 경로만 허용하며 각 root를 벗어나는 경로는 차단한다. report나 controller는 manifest의 경로·SHA-256·schema·proof/PASS/FAIL count를 proof_hard_gate.py로 다시 확인한다.

python3 harness/runtime/proof_runner.py '<proof-request.json>' \
  --repo-root . --run-root '<run-root>' \
  --output '<run-root>/proof-manifest.json'

python3 harness/runtime/proof_hard_gate.py '<run-root>/proof-manifest.json' \
  --repo-root . --run-root '<run-root>' \
  --manifest-sha256 '<sha256>' \
  --proof-count '<N>' --pass-count '<N>' --fail-count 0

Pre-send check

1. draft에 남은 모든 quote가 request와 manifest에 존재하는가?
2. runner와 hard gate가 모두 exit 0, status PASS인가?
3. proof_count == pass_count, fail_count == 0인가?
4. manifest path·hash·schema·count가 보고서의 §7.1과 일치하는가?
5. 실패 proof와 line correction은 모두 본문에 드러냈는가?

하나라도 실패하면 해당 finding을 제거하거나 보고서를 BLOCKED로 판정한다. 대표 PASS proof 1~3개는 가독성을 위해 펼칠 수 있지만, 표시 개수는 검증 count의 근거가 아니다. 전체 count는 persisted manifest와 standalone hard gate 결과만 소유한다.

Contract 7 — Forbidden Marketing Words & External Evidence

Past failure: the agent's findings are mostly grounded, but the prose layered on top inflates them. Words like "100%", "완벽", "극한", "역사상 가장" add no engineering meaning and signal that the agent is generating marketing copy on top of real analysis. Separately, claims of "well-known anti-pattern" or "industry standard practice" without an external citation are unverifiable appeals to authority.

This contract bans marketing inflation and forces external citations for industry-norm claims.

Banned phrases in advisory text

The following words and phrases are forbidden in §1 Executive Summary, §4 Per-File Findings, §5 Priority Recommendations, and Direct-Response answers. They are allowed only inside a verbatim quote (in which case they are accurately citing what the source actually said).

Marketing inflation:

• 100%, 100점, 0% (as a perfection claim — 0 errors observed is OK, 0%까지 완벽 보장 is not)
• 완벽, 완벽히, 완벽한, 완벽무결, 완전무결
• 극한, 극도, 극단적, 극심하게, 극대화
• 절대, 절대적, 절대로 (when used as universal quantifiers — 절대로 일어나서는 안 된다 is OK as a normative statement, 절대로 일어나지 않는다 as a factual claim is not)
• 최강, 최고, 최정상
• 역사상 가장, 사상 최고, 세계 최초
• 즉시, 즉각 (when paired with hyperbolic claims like 즉시 다운, 즉각 폭사)
• 폭사, 사살, 섬멸 (사용자 환경에 대한 비유적 과장)
• 명품, 초일류, 엔터프라이즈급 (자기 평가)

Banned authority-appeals without citation:

• well-known anti-pattern, standard practice, industry consensus, widely accepted, everybody knows
• 대기업에서는, 현업에서는, 실무에서는 — when used to authorize a claim without a specific source. (Acceptable when the agent's own experience/reasoning is what's offered, but then the claim is INFERENCE, not authority.)
• AWS/Google/Netflix가 이렇게 합니다 — without a specific public doc/talk URL or CLAUDE.md / templates/<x>.md cross-reference.

Replacement guidance

Banned	Replacement
100% 무결한 멱등성 보장	중복 결제 케이스 N개 차단. 잔여 엣지 케이스: <list>
완벽한 보안 격리	이 시나리오 하에서 격리됨. <Y> 시나리오는 별도 통제 필요
극한으로 깎인 스켈레톤	현재 명세 기준 N개 결함 식별, M개는 자동 검증 가능
즉시 폭사	<X초> 내에 응답 시간이 <Y배> 증가, 임계치 초과 시 알람
well-known anti-pattern	외부 문서 URL 인용 + 한 문장 인용. 인용 불가 시 INFERENCE 라벨

External evidence requirement

권고가 "이게 표준 / 업계 모범 / RFC / 공식 패턴이다" 라는 권위에 호소하면, 해당 권고는 다음 중 하나여야 한다.

1. 외부 문서 인용: RFC, AWS/GCP/Azure 공식 문서, 공식 프레임워크 reference docs (Spring, Django, Rails 등), OWASP, 또는 명확한 저자가 있는 기술 블로그를 인용한다. URL 또는 문서 명칭(RFC 8594, Spring Boot reference docs §6.4, OWASP Top 10 A03, Vaughn Vernon "Implementing DDD" Ch. 10 등) 명시. 본 wiki의 raw/official-docs/ 또는 raw/company-tech-blogs/ 에 이미 발췌·보존된 자료라면 해당 raw 파일 wikilink + 원문 URL 동시 명시.
2. LLM Wiki CLAUDE.md / templates/ / 기존 wiki 문서 인용*: 본 저장소가 자체적으로 채택한 결정 또는 정책이라면 그 결정 라인을 verbatim quote 로 인용 (예: CLAUDE.md §15 파이프라인 강제, templates/linking-rules.md §2 Mandatory Upward Link 표).
3. INFERENCE 라벨: 외부 근거가 없다면 권고를 INFERENCE로 라벨링하고, "제가 reasoning한 결과"라고 명시. 자기 추론은 합법적이지만 권위 호소로 위장하면 안 된다.

Pre-send check (Contract 7)

송신 직전, 에이전트는 자기 draft를 다음 기준으로 점검한다.

1. 금지 단어 grep: egrep -oh '(100%|완벽|극한|극도|절대로|최강|역사상)' <draft.md> 결과가 비어 있는가? (verbatim quote 내부 등장만 허용)
2. well-known/standard practice/industry consensus/대기업에서는/현업에서는 등의 표현이 등장한 곳마다 외부 문서 URL 또는 명세 인용이 함께 있는가?
3. 권위 호소가 있는데 인용이 없는 경우 해당 finding을 INFERENCE로 라벨링했는가?

위반 1건이라도 발견되면 draft는 BLOCKED 및 재작성.

Concept Organization Mode

When the user asks for a concept explanation, terminology clarification, or "교통 정리" of an area they have not thought through, the agent uses this expansion of the direct-response template:

## 1. 개념 정의 / Concept definition
- <짧고 정확한 정의>
- 흔한 오해 / Common confusions: ...

## 2. 구성 요소 / Components
- <subcomponents or related sub-concepts, each defined once>

## 3. 적용 / Where it applies
- <real situations where the concept matters in this project>

## 4. 대안 / Alternatives and adjacent concepts
- <other ways to model the same problem, with one-line trade-offs>

## 5. 이 wiki / 프로젝트에서의 적용 / How it applies here
- <link to CLAUDE.md / templates/<x>.md / 기존 wiki/concepts/<...>.md / 관련 raw/branch-notes 등 본 개념이 이미 등장하는 파일>
- <gaps in the current setup, if any>

## 6. 추천 학습 순서 / Suggested order to internalize
- <if the concept is layered, give the order to study its parts>

Anti-Patterns

Pattern	Why it fails	Replacement
"X를 추천합니다" without conditions	User cannot tell when X is wrong	Conditional recommendation: "If A → X, if B → Y"
One option presented, no alternatives	User cannot tell what they are giving up	Exhaustive Option Enumeration (Contract 2)
"성능이 떨어질 수 있다" / "고려가 필요하다"	Vague worry, not advice	Name the concrete failure mode and trigger condition
Listing only the user's named ordering (1→2→3)	Hides valid dependency-aware alternatives	Derive the dependency DAG and compare materially distinct topological schedules
Plan review returning "looks fine"	No advisory value	Run Contract 3 explicitly, return gap matrix
Long mermaid diagram with no per-finding analysis	Decoration, not advice	Diagrams allowed only as supplement; the analysis carries the meaning
Finding without Original goal field	Cannot tell if this is critique or fabrication	Cite the spec/code line that states the original goal
Bilingual mirror response	User reads it twice	One language, the user's

Pre-Send Depth Check

Before sending any qualifying response, the agent runs this check against its own draft. If any item fails, the draft is BLOCKED and the agent rewrites.

1. Does every finding have all seven fields of the Goal → Assumption → Problem → Action chain (Original goal / Current state / Real-world assumptions / Gap / Required action / Why this action / Alternatives)?
2. Does every Original goal and Current state field include verbatim quote + <path>:<line> location, not paraphrase?
3. Does every finding have at least 1 explicit Real-world assumption with a falsification condition? Findings with 0 assumptions are forbidden — they critique imagined implementations.
4. Are all <path>:<line> citations real (matched against actual file content with verifiable grep), not invented?
5. Are verbatim quotes copied byte-for-byte from source (no paraphrasing inside the quote)?
6. If the user implied or asked about ordering, design choice, or comparison: are dependency constraints and all materially distinct alternatives covered without factorial permutation expansion?
7. For each enumerated option: are the 6 fields (Case, When-it-fits, Considerations, Pros, Cons, Compared) present?
8. Are recommendations conditional (if X → α), not flat?
9. If the response is a plan review: is the gap matrix present?
10. If this is a non-trivial direct response (no subagent): are the applicable §1~§6 sections present? If it is a trivial lookup, is the answer a concise fact plus citation without empty N/A sections?
11. Is the response in the user's language?
12. Is the response free of vague worries (성능이 떨어질 수 있다) and free of bare opinions (고려가 필요합니다)?
13. Are all citations using workspace-relative paths (no /home/... absolute paths)?
14. For external source directories outside the workspace, is there a §0 Source roots block at the top of the report mapping short names to absolute paths?
15. Self-grep verification (Contract 6): for every verbatim quote in the draft, did the agent actually run sed -n '<line>p' '<file>' or grep -nF -- '<quote>' '<file>' and observe the quote in the output? Quotes that were not verified — or were verified but did not match — must be removed or the finding BLOCKED. Citations are not honest until the command has been run.
16. Verdict math (§3-1): is the Verdict: label exactly the value computed by the §3-1 algorithm from (a)~(f) values in §3? Self-chosen labels that contradict the math are dishonest and force BLOCKED.
17. Single-finding justification: every §4 subsection with exactly 1 finding includes the mandatory justification block (단순 명세 / 전수 통과 + 1결함 / PARTIAL / 단일 critical) with concrete supporting facts (file line count, item list, etc.). Generic prose without facts → BLOCKED.
18. Depth disclosure (§3 (f)): if the count of §4 subsections is less than the count of READ_FULL + READ_PARTIAL rows in §2, are the missing files explicitly listed in the "분석 깊이 미달 파일 명세" table of §3 with reasons? Hiding the gap as "차이 0" while §4 lacks subsections is dishonest and forces BLOCKED.
19. Counterarguments (Contract 1): does every finding include at least 1 explicit Counterargument scenario (반대 논거) where the recommendation could be wrong or unnecessary, with a user-verification check? Zero counterarguments → BLOCKED (the agent has not self-critiqued).
20. Forbidden phrases (Contract 7): is the draft free of banned marketing words (100%, 완벽, 극한, 절대로, 최강, 역사상 가장, 폭사, 명품 etc.) outside verbatim quotes? Are authority appeals (well-known, standard practice, industry consensus, 대기업/현업에서는) backed by RFC/official-doc citations or explicitly labeled INFERENCE? Violation → BLOCKED.
21. Sampling honesty (Contract 6 sampling): is V (검증한 quote 수) in §7.1 equal to the number of sed/grep commands actually written in §7.1? Not extrapolated from a small sample. Unverified quotes labeled UNVERIFIED, not "통과".

If the agent realizes mid-write that it cannot fill the Goal field for a finding (because the source spec was not actually read), it stops, marks that finding INFERENCE, and either reads the source or removes the finding. If the agent realizes it cannot state a clear Real-world assumption (because it does not actually know what assumption it is making), the finding is removed entirely — it was projection, not analysis. If the agent realizes the cited line does not contain the quoted text after running grep, the finding is removed entirely and any related Priority Recommendation referencing it is also removed. Apologies and confidence do not substitute for depth.