agentic-dev 0.2.11 → 0.2.12

package/.codex/skills/sdd/SKILL.md

@@ -1,189 +0,0 @@
----
-name: sdd
-description: "Use for any software development request in a repository that treats `sdd/` as the canonical delivery system. Trigger on requests like develop, implement, build, code, work on, modify, fix, patch, refactor, test, verify, deploy, monitor, or screen/UI-driven prompts such as 화면명세서, 화면설계서, 화면 설계, 화면, 화면 스펙, UI, 디자인, 디자인 가이드, screen spec, screen design, or design guide. The workflow is always SDD-first: inspect and update `sdd/01_planning`, create or update the task plan under `sdd/02_plan`, implement the change, record execution in `sdd/03_build`, capture validation in `sdd/03_verify`, and record deployment or monitoring in `sdd/05_operate` when rollout happens."
----
-
-# SDD Development
-
-## Overview
-
-Use this skill for implementation work in repositories that treat `sdd/` as the canonical delivery record.
-
-This skill enforces one workflow:
-1. inspect and fix relevant `sdd/01_planning` artifacts first,
-2. create or update the task plan under `sdd/02_plan/<section>/`,
-3. perform the code work,
-4. record the current implementation summary in `sdd/03_build`,
-5. record the current retained verification summary in `sdd/03_verify`,
-6. record deployment and monitoring outcomes in `sdd/05_operate` when rollout happens.
-
-When rollout is explicitly in scope, and the repository has separate DEV and PROD environments, this skill enforces a staged release rule: deploy to DEV first, complete the retained full-layer validation surface there, promote to PROD only after DEV passes, then rerun the same retained validation surface in PROD. If PROD validation fails, rollback is required unless the user explicitly redirects and that risk is recorded.
-For persistence-affecting work, this skill also enforces schema-parity verification. Always compare migration or model intent against the real DEV and PROD schema state for the affected database objects instead of assuming deployed reality matches the code.
-Unless the user explicitly forbids it, durable work is not complete at code-edit state. Finish with a coherent git commit, push the retained result to the configured remote, and if the repository ships an installable package or CLI, publish the new version and verify the registry reflects it.
-
-Read [references/section-map.md](references/section-map.md) when you need the exact destination inside `sdd/`.
-For screen-spec-driven UI work, reusable static assets from the spec must be extracted through the repo's canonical asset builder before being used in code.
-For screen-spec-driven layout work, inspect the repo's canonical design guide builder first when one exists.
-For local screen exactness, treat the repo's Playwright exactness runner and suite registry as the canonical automation gate when they exist.
-For verification work, treat regression scope selection as a required retained artifact and carry it through `sdd/02_plan`, `sdd/03_build`, and `sdd/03_verify`.
-Do not infer rollout scope from the existence of `sdd/05_operate` alone; require rollout only when the user asks for deployment or the repo's current policy/plan makes rollout part of completion.
-When a repo or team treats DEV deployment from `main` as the completion bar, temporary branches or worktrees are only working space. Before calling the task deployed, land the final retained change on `main` and push `origin/main`.
-
-## When To Use
-
-Use this skill when:
-- the repository has `sdd/01_planning`, `02_plan`, `03_build`, `03_verify`, `05_operate`,
-- the user gives a development instruction such as `개발해`, `작업해`, `구현해`, `수정해`, `고쳐`, `리팩토링해`, `테스트해`, `배포해`,
-- the user asks for screen/UI work with prompts such as `화면명세서`, `화면설계서`, `화면 설계`, `화면`, `화면 스펙`, `UI`, `디자인`, `디자인 가이드`, `screen spec`, `screen design`, or `design guide`,
-- the user wants work to be traceable through those folders,
-- the task includes both implementation and documentation/verification updates,
-- the task may end in deployment or operational follow-up.
-
-Do not use this skill for:
-- casual questions with no repo changes,
-- one-off local debugging where no durable SDD record is needed,
-- repositories that do not use `sdd/` as their primary document system.
-
-## Workflow
-
-### 1. Inspect Planning First
-
-- Identify the impacted planning area before editing code.
-- Open only the relevant artifacts in `sdd/01_planning`:
-  - feature
-  - screen
-  - architecture
-  - data
-  - api
-  - iac
-  - integration
-  - nonfunctional
-  - security
-  - test
-- If the implementation has already drifted from planning, update the planning artifact first or at least record the drift before coding.
-
-### 2. Create Or Update The Plan
-
-- Create or reuse a durable plan file under `sdd/02_plan/<section>/`.
-- Prefer the repo's planning scaffold if available.
-- The plan must include:
-  - scope
-  - assumptions
-  - acceptance criteria
-  - execution checklist
-  - current notes
-  - validation
-- For any task that may end in deployment, acceptance criteria must explicitly include the DEV gate, the matching PROD gate, the retained full-layer test surface, and the rollback trigger/path.
-- For any task that touches persistence, models, repositories, migrations, SQL, ORM mappings, or runtime failures that may involve schema drift, acceptance criteria must explicitly include DEV/PROD schema verification.
-- Keep exactly one checklist item in progress.
-
-### 3. Implement Against The Plan
-
-- Make code changes only after the impacted planning artifact and plan are aligned enough to proceed.
-- Update the plan current notes after meaningful edits or decisions.
-- When document generators or capture pipelines are involved, keep those tools under `sdd/99_toolchain`.
-- For local screen exactness, treat Playwright as the canonical automation gate unless the repo documents a stronger exact gate for that surface.
-  - In repos created from this template, prefer `python3 sdd/99_toolchain/01_automation/run_playwright_exactness.py --suite <suite-id>` over ad-hoc `npx playwright test ...`.
-  - Keep the suite registry in `sdd/99_toolchain/01_automation/playwright_exactness_manifest.py`.
-  - Browser Use, manual screenshots, or semantic extraction can supplement diagnosis, but they do not replace the retained Playwright exactness gate when a suite exists.
-  - If the needed suite does not exist yet, add or extend it in the same task and register it before calling the work complete.
-- When the task depends on icons, logos, illustrations, or other static assets visible in a screen spec, use the repo's canonical Asset Spec Builder first.
-  - In repos created from this template, this is typically `sdd/99_toolchain/01_automation/spec_asset_builder.py` or a wrapper/manifest around it.
-  - Reusable asset planning records belong under `sdd/01_planning/02_screen/assets/`.
-  - Build the runtime asset from the approved PDF/image source instead of hand-tracing or screenshot-cropping it.
-  - Use exact verification such as `--verify-exact` when the asset is expected to match the source crop exactly.
-  - Record the source, manifest, generated asset path, and any exception in `sdd/03_build` and `sdd/03_verify`.
-  - Only fall back to manual recreation when the builder cannot express the asset, and explicitly document that exception in the plan/build/verify trail.
-- When the task depends on spacing, layout density, typography, color rhythm, or component hierarchy derived from a screen spec, inspect the repo's canonical design guide builder first.
-  - In repos created from this template, inspect `sdd/99_toolchain/01_automation/README.md` and use the actual builder, wrapper, or manifest that exists in the repo.
-  - Use the generated guide as the working baseline before manual spacing or palette tweaks.
-  - If the repo does not provide a design guide builder yet, document the manual interpretation source in plan/build/verify.
-- Define the regression surface before calling implementation complete.
-  - Start from `sdd/02_plan/10_test/regression_verification.md`.
-  - Identify the direct target plus any upstream, downstream, and shared surfaces affected by the change.
-  - If the change touches shared routing, shell/auth, shared state, common components, contracts, generated assets, or builder output, widen the regression scope instead of validating only the edited module.
-  - Record the selected regression scope and any justified exclusions in plan/build/verify.
-- When rollout is in scope, define one retained full-layer validation surface and reuse it in DEV and PROD.
-  - Include the relevant app/runtime entrypoints, API/contracts, persistence/schema, jobs or workflow side effects, shared integrations, and health/monitoring checks affected by the change.
-  - Do not promote to PROD with a narrower verification surface than the DEV gate unless the user explicitly approves that exception and it is recorded.
-
-### 4. Record Build Summary
-
-- Record what you implemented in `sdd/03_build`.
-- Use:
-  - `03_build/01_feature` for feature implementation summaries
-  - `03_build/02_screen` for screen implementation summaries
-  - `03_build/03_architecture`, `06_iac`, `10_test` for current-state cross-cutting summaries
-- Keep entries factual and current-state only: implemented scope, modules, assets, contracts, and current user-visible behavior.
-
-### 5. Record Verification
-
-- Record retained verification status in `sdd/03_verify`.
-- Use:
-  - `03_verify/01_feature` for feature verification summaries
-  - `03_verify/02_screen` for screen verification summaries
-  - `03_verify/03_architecture`, `06_iac`, `10_test` for current retained checks and residual risk
-- Never claim completion without command-level validation evidence.
-- For staged DEV -> PROD rollout, verification must use the same retained full-layer validation surface in both environments.
-  - Run the full-layer validation in DEV after deployment and treat it as a hard gate before PROD promotion.
-  - After PROD deployment, rerun the same retained validation surface in PROD.
-  - If PROD validation fails, execute rollback or the approved recovery procedure immediately and record the failure and recovery outcome.
-- For persistence-affecting work, verification must include real schema evidence from both DEV and PROD when those environments exist.
-  - Check migration state and actual runtime schema separately.
-  - Validate the tables, columns, indexes, constraints, triggers, defaults, and any legacy compatibility objects touched by the change.
-  - Record the commands or queries used, the environments checked, and the drift or parity result.
-- Regression verification is mandatory.
-  - Verification must cover the direct surface and the retained upstream/downstream/shared surfaces selected from the regression baseline.
-  - If no automation exists for a needed regression slice yet, run the best available manual or command checks and record that gap as current residual risk.
-  - When a Playwright suite exists for the surface, record the canonical runner command, suite id, screenshot/json artifact paths, and any live-vs-local split explicitly.
-
-### 6. Record Operate Outcomes
-
-- If deployment or runtime follow-up happens, update `sdd/05_operate`.
-- Use:
-  - `05_operate/01_runbooks` for durable operating procedure changes
-  - `05_operate/02_delivery_status` for the current live state and monitoring baseline
-- Record:
-  - what was deployed
-  - which live baseline is current
-  - how it is monitored
-  - any current residual risk
-- For staged DEV -> PROD rollout, record the DEV gate, PROD gate, and any rollback outcome explicitly.
-- When the DEV deployment baseline is tied to `main`, do not treat a side-branch push as sufficient. Merge, cherry-pick, or otherwise replay the final change onto `main`, push `origin/main`, then record the deployment evidence against that `main` baseline.
-
-## Guardrails
-
-- Do not create or repopulate a parallel `docs/` tree when `sdd/` exists.
-- Do not skip planning review just because the code change looks small.
-- Do not leave build, verify, or operate evidence only in chat text when it should live in `sdd/`.
-- Do not stop after local edits when durable changes remain; commit and push are the default completion bar unless the user explicitly forbids them.
-- Do not leave a publishable package or CLI unpublished after changing shipped behavior or instructions unless the user explicitly forbids publish.
-- When PROD rollout is in scope, do not promote to PROD before the retained full-layer DEV validation surface has passed.
-- When PROD rollout is in scope, do not use a weaker PROD validation surface than the one that gated DEV unless the user explicitly approves and that risk is recorded.
-- When PROD rollout is in scope, do not stop at "PROD deployment succeeded"; post-deploy PROD validation is mandatory.
-- When PROD rollout is in scope, do not leave a failed PROD deployment unreconciled; rollback or the approved recovery procedure must be executed and recorded.
-- Do not assume local tests, migration heads, or current model code prove deployed schema parity.
-- Do not skip DEV/PROD schema inspection for persistence-affecting work when schema drift could influence behavior.
-- Do not manually redraw screen-spec static assets when a canonical Asset Spec Builder exists for the repo; extract them first and use the generated asset.
-- Do not skip a relevant screen automation builder just because the requested UI change looks like a small manual tweak.
-- Do not stop verification at the edited file, route, or screen when the change can affect shared or adjacent behavior.
-- Do not omit regression scope selection from the retained SDD trail.
-- Do not update `05_operate` for tasks that never reached deployment; explicitly note that rollout did not happen instead.
-- Do not call a DEV rollout complete from a temporary branch when the repo or team baseline expects the deployed change to be on `origin/main`.
-
-## Output Standard
-
-By the end of an implementation task, the expected trail is:
-- planning artifact reviewed or corrected,
-- plan file updated,
-- build summary written,
-- verification summary written, including selected regression scope and residual risk,
-- operate status updated if rollout occurred,
-- coherent git commit created and pushed,
-- publishable package/CLI인 경우 registry publish and latest verification completed unless the user explicitly forbade it.
-
-When PROD rollout is in scope, the retained completion state also requires:
-- DEV deployment happened first and the retained full-layer DEV validation surface passed,
-- the same retained full-layer validation surface was executed again in PROD,
-- DEV/PROD schema state was checked and recorded when schema could influence behavior,
-- any PROD validation failure produced rollback or recovery evidence in verify/operate.

package/.codex/skills/sdd/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SDD Development"
-  short_description: "Use SDD-first flow with schema parity, regression scope, and staged rollout gates"
-  default_prompt: "Use $sdd to handle this development task through sdd planning, build, verify, and operate, including regression scope selection, schema parity checks for persistence-affecting work, and staged DEV-first validation when multiple environments exist."

package/.codex/skills/sdd/references/section-map.md

@@ -1,67 +0,0 @@
-# SDD Section Map
-
-## Planning
-
-- `sdd/01_planning/01_feature`
-  - domain or service feature specifications
-- `sdd/01_planning/02_screen`
-  - service-level screen specifications and PDFs
-- `sdd/01_planning/03_architecture`
-  - bounded context, runtime, and structural design
-- `sdd/01_planning/04_data`
-  - data model and relationship definitions
-- `sdd/01_planning/05_api`
-  - transport contracts and API definitions
-- `sdd/01_planning/06_iac`
-  - infrastructure planning and deployment design
-- `sdd/01_planning/07_integration`
-  - integration contracts and external dependency planning
-- `sdd/01_planning/08_nonfunctional`
-  - performance, reliability, scalability, and operational constraints
-- `sdd/01_planning/09_security`
-  - security posture, threat model, and control planning
-- `sdd/01_planning/10_test`
-  - test strategy and planned cases
-
-## Plan
-
-- `sdd/02_plan/<section>`
-  - executable plan files and migration backlogs
-
-## Build
-
-- `sdd/03_build/01_feature`
-  - feature implementation summaries
-- `sdd/03_build/02_screen`
-  - screen implementation summaries
-- `sdd/03_build/03_architecture`
-  - structural and governance implementation summaries
-- `sdd/03_build/06_iac`
-  - current delivery/runtime implementation summaries
-- `sdd/03_build/10_test`
-  - current harness and validation implementation summaries
-
-## Verify
-
-- `sdd/03_verify/01_feature`
-  - feature verification summaries
-- `sdd/03_verify/02_screen`
-  - screen verification summaries
-- `sdd/03_verify/03_architecture`
-  - governance and structure verification summaries
-- `sdd/03_verify/06_iac`
-  - delivery/runtime verification summaries
-- `sdd/03_verify/10_test`
-  - current harness outputs and retained validation references
-
-## Operate
-
-- `sdd/05_operate/01_runbooks`
-  - durable operating procedures
-- `sdd/05_operate/02_delivery_status`
-  - current live state, monitoring baseline, and residual risk
-
-## Tooling
-
-- `sdd/99_toolchain`
-  - generators, capture tooling, manifests, and other SDD automation

package/.dockerignore

@@ -1,8 +0,0 @@
-.git
-node_modules
-**/node_modules
-**/dist
-**/.venv
-**/__pycache__
-**/.pytest_cache
-**/*.tsbuildinfo

package/.env.example

@@ -1,50 +0,0 @@
-SERVER_HTTP_PORT=8000
-CLIENT_LANDING_PORT=3000
-CLIENT_WEB_PORT=3001
-CLIENT_MOBILE_PORT=3002
-CLIENT_ADMIN_PORT=4000
-
-POSTGRES_PORT=5432
-POSTGRES_DB=template
-POSTGRES_USER=template
-POSTGRES_PASSWORD=template
-
-MYSQL_PORT=3306
-MYSQL_DATABASE=template
-MYSQL_USER=template
-MYSQL_PASSWORD=template
-MYSQL_ROOT_PASSWORD=template-root
-
-MARIADB_PORT=3307
-MARIADB_DATABASE=template
-MARIADB_USER=template
-MARIADB_PASSWORD=template
-MARIADB_ROOT_PASSWORD=template-root
-
-MONGO_PORT=27017
-
-SERVER_APP_NAME=Template Server
-SERVER_ENVIRONMENT=development
-SERVER_API_PREFIX=/api/v1
-SERVER_DATABASE_BACKEND=postgres
-SERVER_POSTGRES_URL=postgresql+psycopg://template:template@postgres:5432/template
-SERVER_MYSQL_URL=mysql+pymysql://template:template@mysql:3306/template
-SERVER_MARIADB_URL=mysql+pymysql://template:template@mariadb:3306/template
-SERVER_MONGODB_URL=mongodb://mongo:27017
-SERVER_MONGODB_DATABASE=template
-SERVER_JWT_SECRET=template-local-dev-secret
-SERVER_JWT_ALGORITHM=HS256
-SERVER_ACCESS_TOKEN_TTL_MINUTES=120
-SERVER_BOOTSTRAP_ADMIN_EMAIL=admin@example.com
-SERVER_BOOTSTRAP_ADMIN_PASSWORD=change-me-admin
-SERVER_BOOTSTRAP_ADMIN_NAME=Template Admin
-SERVER_BOOTSTRAP_OPERATOR_EMAIL=operator@example.com
-SERVER_BOOTSTRAP_OPERATOR_PASSWORD=change-me-operator
-SERVER_BOOTSTRAP_OPERATOR_NAME=Template Operator
-SERVER_CORS_ORIGINS=["http://localhost:3000","http://127.0.0.1:3000","http://localhost:3001","http://127.0.0.1:3001","http://localhost:3002","http://127.0.0.1:3002","http://localhost:4000","http://127.0.0.1:4000"]
-
-CLIENT_LANDING_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
-CLIENT_WEB_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
-CLIENT_MOBILE_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
-CLIENT_ADMIN_VITE_API_BASE_URL=http://127.0.0.1:8000/api/v1
-CLIENT_WATCH_USE_POLLING=false

package/.gitignore

@@ -1,16 +0,0 @@
-node_modules/
-dist/
-.DS_Store
-*.tsbuildinfo
-.venv/
-__pycache__/
-.pytest_cache/
-.terraform/
-.agent/runs/**
-!.agent/runs/
-!.agent/runs/README.md
-!.agent/sdd-build-ast-audit.json
-!.claude/settings.local.json
-.codex/skills/dev-browser/node_modules/
-.codex/skills/dev-browser/profiles/browser-data/
-.tmp-agentic-smoke/

package/AGENTS.md

@@ -1,86 +0,0 @@
-# AGENTS.md
-
-## Toolchain Convention Policy
-
-- 저장소 공통 컨벤션, 워크플로우, 실행 규약의 정본은 항상 `sdd/99_toolchain/02_policies`에 저장한다.
-- `AGENTS.md`는 핵심 실행 규칙과 우선순위만 요약하며, 상세 배경/예외/절차는 toolchain 정책 문서를 따른다.
-
-## Regression Verification Policy
-
-- `sdd` 성격의 작업은 edited target만 확인하고 종료하지 않는다.
-- 회귀 검수 범위는 `sdd/02_plan/10_test/regression_verification.md` 기준으로 direct, upstream, downstream, shared surface까지 선택한다.
-- Playwright exactness suite가 있는 UI surface는 `sdd/99_toolchain/01_automation/run_playwright_exactness.py`를 canonical local gate로 사용한다.
-- shared route, shell, auth/session, component, data contract, generated asset, builder output 변경은 adjacent consumer까지 검수 범위를 넓힌다.
-- 선택한 회귀 범위, 생략 사유, residual risk는 `sdd/02_plan`, `sdd/03_build`, `sdd/03_verify`에 current-state로 남긴다.
-
-## Branch And Deploy Policy
-
-- 코드베이스 기본 개발 브랜치는 `main`이다.
-- 구현 작업은 기본적으로 task 성격에 맞는 work branch에서 시작한다.
-- work branch는 `feat/...`, `fix/...`, `refactor/...`, `docs/...`, `test/...`처럼 작업 surface가 드러나는 이름을 사용한다.
-- work branch의 변경은 원격 branch까지 먼저 push해 working integration baseline을 남긴다.
-- `main`이 아닌 branch에서 agent turn이 끝날 때 durable 변경이 남아 있으면 기본적으로 그 branch에 coherent commit을 만들고 origin branch까지 push한다. 예외는 worktree가 이미 clean이거나 사용자가 그 turn에 commit/push를 금지한 경우뿐이다.
-- `DEV(개발계)` 반영이 필요한 작업은 그 branch를 `main`에 반영하고 `origin/main`까지 push한 뒤 배포한다.
-- 수동 배포 단계여도 `branch push -> main merge/push -> DEV 배포 -> DEV 검증` 순서를 생략하지 않는다.
-- 완료된 work branch는 관련 정합성 체크가 끝나고 변경이 `main`과 `origin/main`에 안전하게 반영된 뒤 local/remote branch를 모두 삭제한다. 사용자가 branch 유지를 명시한 경우만 예외다.
-- branch retire 전 최소 정합성 체크는 `관련 canonical 검증 명령 재실행`, `worktree clean 확인`, `최종 변경의 main 포함 여부 확인`이다.
-
-## Completion And Release Policy
-
-- 사용자가 명시적으로 금지하지 않는 한, durable 변경이 남은 agent 작업은 `commit -> push -> publish 가능한 패키지/CLI는 publish`까지 끝나야 완료로 간주한다.
-- "설명만 하고 종료", "로컬 수정만 남기고 종료", "커밋 없이 종료", "원격 미반영 상태로 종료"는 기본 완료 상태가 아니다.
-- npm package, 설치형 CLI, 배포 artifact처럼 사용자가 즉시 받는 deliverable을 가진 저장소는 변경 후 새 버전을 발행하고 registry 배포까지 확인한다.
-- publish 가능한 저장소에서 publish를 생략할 수 있는 예외는 사용자가 그 turn에서 명시적으로 금지한 경우뿐이다.
-- 완료 보고 전 최소 확인 항목은 `coherent commit 존재`, `원격 push 완료`, `publish 대상이면 registry 최신 반영 확인`이다.
-
-## Runtime Naming Policy
-
-- 문서/대화/로그에서 실행 환경은 항상 `DEV(개발계)`로 표기한다.
-- `local`, `localhost 환경` 같은 표현은 운영 용어로 사용하지 않는다.
-
-## SDD Placement Rule
-
-- 이 저장소는 top-level `docs/` 트리를 사용하지 않는다.
-- design, planning, execution, verification, operate 문서는 모두 `sdd/` 아래에 둔다.
-- 모든 `sdd/` section은 overwrite-only current-state artifact다.
-- 날짜별 history, archive, release-log, gate-log 성 문서는 `sdd/` 안에 유지하지 않는다.
-- durable plan artifact는 항상 `sdd/02_plan/<section>/` 아래에 둔다.
-
-## SDD Plan Governance
-
-- `sdd/02_plan`은 dated or archived planning history를 두지 않는다.
-- `sdd/02_plan`은 에이전트의 현재 개발 계획을 기록하는 루트다.
-- feature, screen, architecture, data, API, IAC, integration, nonfunctional, security, test planning은 durable target-specific 문서를 직접 갱신한다.
-- feature plan 기본 경로는 `sdd/02_plan/01_feature/<domain>_todos.md`다.
-- screen plan 기본 경로는 `sdd/02_plan/02_screen/<service>_todos.md`다.
-- 개발계 반영이 필요한 작업은 `구현(branch) -> branch push -> build -> main merge/push -> DEV(개발계) 배포 -> DEV 검수 -> 문서 갱신 -> branch 삭제` 순서를 기본 루틴으로 사용한다.
-- 횡단 작업도 날짜 파일을 추가하지 않고 같은 section의 governance/backlog/current-plan 문서를 덮어쓴다.
-
-## SDD Build Governance
-
-- `sdd/03_build`는 `sdd/02_plan`의 top-level split을 따라 durable implementation summary를 유지한다.
-- feature summary는 service 또는 domain-sized category로 묶고, screen summary는 service split을 따른다.
-- screen build summary는 `sdd/03_build/02_screen/<service>/` 아래 screen-specific 파일로 유지한다.
-- dated execution log는 두지 않고 같은 summary 파일을 갱신한다.
-
-## SDD Verify Governance
-
-- `sdd/03_verify`는 feature/screen/architecture/IAC/test별 current verification summary만 유지한다.
-- screen verification summary는 `sdd/03_verify/02_screen/<service>/` 아래 screen-specific 파일로 유지한다.
-- dated gate result나 test evidence log는 남기지 않는다.
-
-## SDD Operate Governance
-
-- `sdd/05_operate`는 current delivery state, runbook, monitoring baseline만 유지한다.
-- raw runtime log나 release timeline은 SDD가 아니라 runtime logging system의 역할이다.
-
-## Harness Location Policy
-
-- Claude/Codex/Ralph 하네스와 에이전트 설정은 저장소 루트의 `.claude`, `.codex`, `.agent`와 `sdd/99_toolchain/01_automation` 설명 문서에 함께 유지한다.
-
-## Build AST Governance
-
-- `sdd/03_build`는 실행 이력 요약이 아니라 runtime assembly current-state 문서다.
-- service/screen build summary는 `entry -> provider/router -> auth/session gate -> shell -> route leaf -> backend contract leaf` 순서를 우선 유지한다.
-- `sdd/03_build`에는 dated history, Ralph iteration narrative, run id memo를 남기지 않는다.
-- AST 기반 current-state 적합성은 `scripts/dev/audit_sdd_build_ast.py`와 `sdd/03_verify/03_architecture/build_ast_runtime_tree_governance.md`를 기준으로 관리한다.