docs: Step 1 (ADR+architecture stub) + Step 2 (미분류 문서 매핑) — refs #518

docs/adr/ADR-0001-ai-dev-boilerplate.md

@@ -1,181 +1,17 @@
 ---
 title: "ADR-0001: Multi-AI Development Boilerplate"
-owner: human
-status: approved
-updated: 2026-04-17
-tags: [harness, agent]
+owner: llm
+status: deprecated
+updated: 2026-05-21
+tags: [architecture, harness, obsidian, deprecated]
 ---
 
 # ADR-0001: Multi-AI Development Boilerplate
 
-## Status
-
-Accepted (v1.0)
-
-## Context
-
-We use multiple AI tools in our development workflow:
-
-- **Claude** (via gstack/Superpowers): For refactors, code analysis, and TDD-driven implementation
-- **Cursor**: Main coding assistant for feature implementation
-- **Gemini**: Documentation generation
-- **Codex**: Spec templates and checklists
-
-Each tool has different strengths and should be used intentionally. Without clear guidelines, developers may:
-
-- Use the wrong tool for a task
-- Waste time figuring out which tool to use
-- Create inconsistent workflows
-- Duplicate effort across tools
-
-## Decision
-
-We will create a dedicated AI playbook structure with:
-
-1. **Shared principles** (`docs/ai-playbook/01-principles.md`):
-   - Language conventions (Korean conversation, English code)
-   - Code quality standards
-   - Safety guidelines
-   - Workflow principles
-
-2. **Tool-specific profiles** (`docs/ai-playbook/*-profile.md`):
-   - Clear role definition for each tool
-   - Usage guidelines and examples
-   - Integration points with other tools
-   - Do's and don'ts
-
-3. **Workflow overview** (`docs/ai-playbook/02-workflow-overview.md`):
-   - How tools work together
-   - Typical workflows for common tasks
-   - Integration with existing infrastructure
-
-4. **Configuration files**:
-   - `.cursor/rules/`: Cursor-specific rules (JSONC format)
-   - `.claude/settings.json`: Claude Code harness configuration
-   - `.codex/config.json`: Codex CLI configuration
-
-5. **Prompt templates** (`docs/prompts/`):
-   - Templates for Gemini documentation generation
-   - Templates for Codex spec generation
-
-6. **Integration with existing infrastructure**:
-   - Integrate with `.claude/` harness workflow (gstack, Superpowers, GSD)
-   - Preserve `.cursor/rules/` for Cursor users
-
-## Consequences
-
-### Positive
-
-- **Clear mental model**: Developers know which tool to use when
-- **Faster onboarding**: New team members understand the workflow quickly
-- **Consistency**: Standardized approach across the team
-- **Better collaboration**: Clear handoffs between tools
-- **Reduced confusion**: Less time spent deciding which tool to use
-
-### Negative
-
-- **Additional maintenance**: More documentation files to keep updated
-- **Learning curve**: Team needs to learn the new structure
-- **Potential rigidity**: May feel restrictive if not balanced with flexibility
-
-### Risks
-
-- **Documentation drift**: Docs may become outdated if not maintained
-- **Over-engineering**: Too much structure can slow down simple tasks
-- **Tool version changes**: Tool updates may require doc updates
-
-### Mitigation
-
-- **Version tracking**: Each profile includes "Last verified with" date
-- **Kill-switch**: If setup time exceeds work time, simplify to core principles
-- **Regular review**: Update docs when tools or workflows change
-- **Flexibility**: Structure is advisory, not mandatory
-
-## Alternatives Considered
-
-### A: Single Source of Truth (Single File)
-
-**Approach**: One `docs/ai-playbook/ai-roles.md` file with all rules
-
-**Rejected because**:
-
-- Less optimized for each tool's format
-- Harder to maintain tool-specific guidance
-- Doesn't leverage tool-specific configuration formats
-
-### B: Tool-Specific Profiles + Shared Principles (Selected)
-
-**Approach**: Separate profiles with shared principles
-
-**Selected because**:
-
-- Best balance of consistency and tool optimization
-- Easier to maintain tool-specific guidance
-- Supports tool-specific configuration formats
-
-### C: Task Pipeline Approach
-
-**Approach**: Process-based documentation (e.g., "small-refactor-claude.md")
-
-**Rejected because**:
-
-- Harder to maintain when tools change
-- Less reusable across different tasks
-- Doesn't provide clear tool roles
-
-## Implementation
-
-### Phase 1: Structure Creation (v1.0)
-
-- Create directory structure
-- Write core principles and tool profiles
-- Create configuration files
-- Set up prompt templates
-
-### Phase 2: Integration (v1.0)
-
-- Integrate with existing `.specify/` infrastructure
-- Update workflow overview with integration points
-- Create ADR document
-
-### Phase 3: Experimentation (v1.1)
-
-- Track usage in `docs/ai-playbook/usage-log.md`
-- Gather feedback from team
-- Refine based on actual usage
-
-### Phase 4: Refinement (v1.1+)
-
-- Update profiles based on learnings
-- Simplify if needed (kill-switch criteria)
-- Maintain version information
-
-## Success Criteria
-
-- **Time to first commit**: Reduced by 50%+ for new tasks
-- **Tool switching frequency**: Reduced confusion about which tool to use
-- **Confusion score**: "Which AI to use when?" score improves (1-5 scale)
-- **Workflow clarity**: Team feels workflow is clear and helpful
-
-## Version History
-
-- **v1.0** (2025-01-27): Initial boilerplate structure
-- **v1.1** (TBD): Updates based on Week 1 usage and feedback
-
-## References
-
-- `docs/ai-playbook/01-principles.md`: Core principles
-- `docs/ai-playbook/02-workflow-overview.md`: Workflow integration
-- `.specify/memory/constitution.md`: Project constitution
-- `.cursor/rules/`: Cursor configuration
-
-## Notes
-
-This ADR documents the decision to create a multi-AI development boilerplate. The structure is designed to be:
-
-- **Flexible**: Can adapt to tool changes
-- **Maintainable**: Clear version tracking and update process
-- **Practical**: Based on actual workflow needs
-- **Evolvable**: Can be simplified if needed (kill-switch criteria)
-
-The boilerplate complements, rather than replaces, existing infrastructure like `.specify/` and `.claude/commands/`.
+> **이 문서는 [decoded-docs vault](https://github.com/decodedcorp/decoded-docs)로 이전되었습니다.**
+>
+> 본문: [`Architecture/adr/ADR-0001-ai-dev-boilerplate.md`](https://github.com/decodedcorp/decoded-docs/blob/main/Architecture/adr/ADR-0001-ai-dev-boilerplate.md)
+>
+> Obsidian path: `Architecture/adr/ADR-0001-ai-dev-boilerplate`
+>
+> Sync policy: [Guides/sync-policy](https://github.com/decodedcorp/decoded-docs/blob/main/Guides/sync-policy.md)

docs/adr/ADR-0002-llm-wiki-foundation.md

@@ -1,64 +1,17 @@
 ---
 title: "ADR-0002: LLM Wiki Foundation"
-owner: human
-status: approved
-updated: 2026-04-17
-tags: [architecture, harness, agent]
-related:
-  - docs/superpowers/specs/2026-04-17-llm-wiki-foundation-design.md
-  - docs/wiki/schema/README.md
+owner: llm
+status: deprecated
+updated: 2026-05-21
+tags: [architecture, harness, obsidian, deprecated]
 ---
 
 # ADR-0002: LLM Wiki Foundation
 
-- **Status:** Accepted (2026-04-17)
-- **Supersedes:** —
-- **Related:** Issue #153, PR #223, Spec `docs/superpowers/specs/2026-04-17-llm-wiki-foundation-design.md`
-
-## Context
-
-decoded-monorepo는 현재 4개 이상의 문서 소스가 공존한다: 루트 `CLAUDE.md`, `.cursor/rules/*.mdc`, `docs/agent/`, `docs/ai-playbook/`, `.planning/codebase/`. 각각 부분적으로 중복된 컨벤션·아키텍처·에이전트 규칙을 담고 있으며 정본(SSOT) 규칙이 없다. 이슈 #153은 이 상태를 정비하면서 Karpathy LLM wiki 컨셉(LLM이 markdown 위키를 자동 ingest/lint/update하는 구조)에서 영감을 얻어 에이전트 하네스 프로그래밍을 업그레이드한다.
-
-## Decision
-
-`docs/` 하위에 LLM wiki 2계층 구조(`docs/wiki/wiki/` + `docs/wiki/schema/`)를 도입한다. Karpathy의 3계층(source/wiki/schema) 중 `source`는 "source = code"인 이 repo 특성상 생략한다. 기존 `docs/agent/`는 topic summary 허브로 확장하고, 기존 topic 폴더(`docs/architecture/` 등)에 distributed `agent.md`를 두지 않는다. 컨벤션·하네스 규칙은 `docs/wiki/schema/`로 정본화하고 `CLAUDE.md`·`.cursor/rules/`는 pointer로 축소한다.
-
-## Alternatives Considered
-
-1. **Do nothing** — 현 상태 유지. 드리프트 지속.
-2. **Flatten everything into `docs/agent/`** — Karpathy 컨셉 포기, 성장 경로 상실.
-3. **Full Karpathy 3계층(source/wiki/schema)** — `source` 계층 억지 적용.
-4. **Consolidation only** (schema 도입 없이 중복만 줄임) — SSOT 구조화 기회 상실.
-
-## Rationale
-
-에이전트 작업 지식의 누적을 허용(hybrid D 기반)하면서, OMC critic·architect 리뷰가 지적한 3가지 위험(distributed `agent.md`, `source` 계층 억지, 자동화 지연)을 동시 회피한다.
-
-## Consequences
-
-### Positive
-
-- 컨벤션 조회 시 정본 1곳으로 수렴 (현재 4+).
-- LLM·Cursor·Claude가 공통 규약 파일을 참조.
-- 에이전트 지식 누적을 받아내는 전용 공간(`wiki/wiki/`) 확보.
-
-### Negative
-
-- 새 디렉토리 도입으로 초기 learning curve.
-- Phase 1 산출물이 Sub-3 자동화 없이 수동 유지. Sub-3 지연 시 drift 위험.
-- 기존 파일 프론트매터 추가·pointer 축소 migration 비용.
-
-## Reversibility
-
-Phase 1 후 2~3개월 내 이 구조가 overhead로 드러나면:
-
-1. 이 ADR을 `Superseded`로 변경하고 사유 기록.
-2. `docs/wiki/schema/**` 삭제 또는 `/archive/` 이동.
-3. PR-C에서 축소한 `CLAUDE.md`·`.cursor/rules/` 컨벤션 섹션을 `git revert`로 복원.
-4. `docs/agent/*-summary.md` 파일은 유지 여부를 파일별로 재평가.
-5. `.planning/codebase/`와 기존 `docs/agent/` 인벤토리는 변경 없이 잔존.
-
-## Implementation
-
-- Plan: `docs/superpowers/plans/2026-04-17-llm-wiki-foundation.md`
-- Follow-ups: Sub-3 (자동화), Sub-4 (CLAUDE.md·.cursor/rules 전면 리팩토링)
+> **이 문서는 [decoded-docs vault](https://github.com/decodedcorp/decoded-docs)로 이전되었습니다.**
+>
+> 본문: [`Architecture/adr/ADR-0002-llm-wiki-foundation.md`](https://github.com/decodedcorp/decoded-docs/blob/main/Architecture/adr/ADR-0002-llm-wiki-foundation.md)
+>
+> Obsidian path: `Architecture/adr/ADR-0002-llm-wiki-foundation`
+>
+> Sync policy: [Guides/sync-policy](https://github.com/decodedcorp/decoded-docs/blob/main/Guides/sync-policy.md)