2nd/10_Wiki/Topic_Programming/AI_and_ML/ADR-0001-project-chronicle-independent-module.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack, applied_in

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	inferred_by	tech_stack	applied_in
wiki-2026-0508-adr-0001-project-chronicle-indep	ADR-0001: Project Chronicle as Independent Module	10_Wiki/Topics	verified	self	ADR-0001 Project Chronicle Guard src/features/projectChronicle	none	A	0.9	applied	adr architecture-decision modular-design project-chronicle antigravity soc		2026-05-09	pending	Claude Opus 4.7 (manual cleanup 2026-05-09)	language framework TypeScript VS Code Extension API	Antigravity ConnectAI

ADR-0001: Project Chronicle as Independent Module

📌 한 줄 통찰 (The Karpathy Summary)

Project Chronicle (planning / decision / log / bug / retro 의 record) 의 chat / agent 와 분리 module 로 implement. SoC 의 적용 — 매 chat / agent 의 regression 의 risk 의 감소.

📖 구조화된 지식 (Synthesized Content)

Status

Accepted (2026-05-02).

Context

• 매 새 feature: project planning, Q, decision, dev log, bug, retro 의 record.
• 매 existing chat / agent system 의 model interaction + agent skill manage.
• 매 새 feature 의 mix vs separate 의 결정.

Decision

Project Chronicle Guard 의 separate module under src/features/projectChronicle.

Reason (왜 separate?)

1. Regression risk ↓: chat / agent 의 active code path 의 untouched.
2. Independent test: 매 module 의 own test suite.
3. Independent deploy: 매 module 의 disable 가능.
4. Clear ownership: 매 team 의 own area.
5. DDD bounded context: chronicle 의 own model / vocabulary.
6. Future evolution: 매 module 의 self-contained → easier extract / refactor.

Alternatives considered

• Embed in agent: chat 의 agent skill 의 추가. Reject: regression 위험 + complexity ↑.
• External service: separate process / container. Reject: deployment overhead.
• Plugin: dynamic load. Reject: complexity premature.

Consequences

Positive:

• Chat / agent 의 stable.
• 매 chronicle 의 independent iterate.
• Test isolation.

Negative:

• Cross-module communication 의 explicit.
• 매 boundary 의 maintain cost.
• 매 user 의 module-aware.

Implementation

src/features/projectChronicle/
├── domain/        # Plan, Decision, Log, Bug, Retro
├── application/   # ChronicleService
├── infrastructure/  # File / DB
├── api/           # Webview / command
└── index.ts       # Public API

→ Hexagonal-ish 의 매 boundary.

Module 의 public API

// src/features/projectChronicle/index.ts
export { ChronicleService } from './application/ChronicleService';
export { Plan, Decision, Log } from './domain';

// 매 다른 module 의 use:
import { ChronicleService } from '@/features/projectChronicle';

💻 패턴 (Code)

Domain model

// domain/Plan.ts
export class Plan {
  constructor(
    public id: string,
    public title: string,
    public goals: string[],
    public createdAt: Date,
    public status: 'draft' | 'active' | 'done'
  ) {}
}

Service

// application/ChronicleService.ts
export class ChronicleService {
  constructor(private store: ChronicleStore) {}
  
  async createPlan(input: PlanInput): Promise<Plan> {
    const plan = new Plan(uuid(), input.title, input.goals, new Date(), 'draft');
    await this.store.savePlan(plan);
    return plan;
  }
}

Wire-up (extension.ts)

import { ChronicleService } from './features/projectChronicle';

export function activate(context: vscode.ExtensionContext) {
  const chronicleService = new ChronicleService(new FileChronicleStore(context));
  
  context.subscriptions.push(
    vscode.commands.registerCommand('chronicle.createPlan', async () => {
      const plan = await chronicleService.createPlan({...});
      vscode.window.showInformationMessage(`Plan ${plan.id} created`);
    })
  );
}

🤔 의사결정 기준 (Decision Criteria)

새 feature 의 추가 시	추천
매 existing module 의 minor extension	Embed
매 distinct domain	Separate module
매 risk of regression	Separate
매 independent lifecycle	Separate
매 team boundary	Separate

기본값: 매 distinct domain = separate module.

🔗 지식 연결 (Graph)

• 부모: ADR (Architecture Decision Record) · Modular-Design · Separation of Concerns

🤖 LLM 활용 힌트

언제 사용: 매 새 feature 의 architecture 의 결정. 매 modular boundary 의 example.

언제 X: 매 small bugfix. 매 prototype.

❌ 안티패턴

• Embed everything: monolith 의 regression.
• Module 의 cross-private access: SoC violation.
• Module 의 own DB without need: over-engineer.

🧪 검증 / 중복

• Verified (applied to Antigravity).
• 신뢰도 A (project's own ADR).
• Related: ADR-0002+ (다른 module).

🕓 Changelog

날짜	변경	처리	신뢰도
2026-05-08	Phase 1 정규화	UPDATE	A
2026-05-09	Manual cleanup — 매 ADR section + code + 결정 기준	UPDATE	A