jungho-git/docs

Docs

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

---

Scope

Use this rule when the user asks for:

• Codex 작업 결과 보고서
• 작업 로그 보고서
• Markdown report from current work
• report update, latest version, duplicate cleanup, or v2/v3 revision
• historical Codex session report from logs

Reports should be Korean, evidence-bound, and directly usable as Markdown artifacts.

---

Scope Resolution

• Identify requested time range, project, session, target report path, and version.
• If no destination is specified, create the report under the agent root .docs/ directory using a clear name.
• Treat the agent root as the agent's home/config directory, not the active project workspace.
• Examples: Codex uses ~/.codex/.docs; Claude uses ~/.claude/.docs.
• Create the agent root .docs/ directory when it does not already exist.
• If the user asks for a new version, create v2, v3, or the requested version.
• If the user asks for update, latest, cleanup, or correction, read the existing report first and update that file.
• Do not overwrite unrelated reports.

Resolve report target before collecting broad evidence.

---

Evidence Sources

Prefer evidence in this order:

• current changed files and generated artifacts
• commands/checks actually run
• git status, diff, and log when repository exists
• final assistant summaries and completion-hook summaries
• Codex session logs and notify logs when historical context is requested
• user-provided notes, labeled as user-provided evidence

For historical logs, use references/log-sources.md.

---

Evidence Labels

• 확인됨: direct artifact, command output, file read, git evidence, or log evidence exists.
• 추론: derived from multiple evidence points but not directly stated.
• 미검증: plausible but not backed by a check.
• 차단됨: required evidence could not be accessed or command could not run.

Do not invent test results, dates, file changes, or completed work.

---

Required Sections

Default report structure:

• 작업 범위: original request, project, target files, report version
• 작업 결과: implemented changes or generated deliverables
• 변경 파일: files actually created or edited
• 검증: commands run, parser checks, file existence checks, format checks
• 문제: failed checks, blockers, skipped checks, residual risk
• 후속 작업: next concrete steps ordered by dependency or priority
• 근거: evidence list with labels

Preserve a user's requested structure when explicitly provided.

---

Writing Rules

• Write in Korean unless the user requests another language.
• Lead with the conclusion.
• Use concise technical prose, not transcript style.
• Include only files actually changed under 변경 파일.
• Preserve exact command names and paths with inline code.
• Use fenced code blocks with language tags only for trees or short command excerpts.
• Sanitize secrets and omit raw auth, token, cookie, and credential content.
• Do not paste raw full logs unless explicitly requested.

Report facts, not chat history.

---

Update Rules

• Preserve the user's chosen title and destination unless they request a new version.
• Merge repeated sections instead of appending duplicates.
• Replace obsolete tree blueprints with one latest blueprint.
• Keep historical findings only when still useful; label superseded findings.
• Update 작성일 or add 최종 업데이트.
• Verify the file after editing.

Update reports as maintained documents, not append-only logs.

---

Verification

• Re-read the report file.
• Confirm title, version, destination, and required sections.
• Confirm Markdown fences open and close correctly.
• Confirm changed-file list matches evidence.
• Confirm every check in 검증 was run or marked not run/could not run.
• Report remaining uncertainty in the final response.

Report generation is not complete until the artifact is checked.

---

Boundaries

• Do not include secrets, raw tokens, cookies, or auth payloads.
• Do not claim validation that was not run.
• Do not invent exact dates from vague memory.
• Do not list unrelated files just because they appeared in logs.
• Do not treat generated caches or temporary files as source evidence unless directly requested.