project-librarian 0.4.2 → 0.4.3

package/README.ko.md

@@ -52,7 +52,7 @@ Project Librarian은 에이전트에게 두 가지 로컬 정본을 제공합니
 | 표면 | 에이전트가 얻는 것 |
 | --- | --- |
 | `wiki/startup.md` + `wiki/index.md` | 짧은 세션 시작 요약과 라우터. 관련 계획 페이지만 읽습니다. |
-| `wiki/canonical/` 및 `wiki/decisions/` | 현재 프로젝트 사실, 제약, 리스크, 패키지 계약, CLI 동작, 지속되는 결정. |
+| `wiki/canonical/`, `wiki/roadmaps/`, `wiki/plans/`, `wiki/decisions/` | 현재 정본은 canonical, 큰 미래 작업은 roadmaps, 상세 실행은 plans, 지속되는 근거는 decisions에 둡니다. |
 | `wiki/meta/document-taxonomy.md` | PRD, 정책, UX, 데이터, 개발, QA, 릴리즈, 운영 정본을 어디에 둘지 안내하는 서비스 생애주기 분류 지도. |
 | `.codex/`, `.claude/`, `.cursor/`, `.gemini/` 훅 | 전체 위키를 불러오지 않는 Codex/Claude Code/Cursor/Gemini CLI 시작 컨텍스트. |
 | `GEMINI.md` 및 `.cursor/rules/` | Gemini CLI와 Cursor를 같은 간결한 위키 우선 계약으로 안내하는 지침 파일. |
@@ -236,6 +236,8 @@ Git 훅 파일:
 위키 디렉터리:
 
 - `wiki/canonical/`
+- `wiki/roadmaps/`
+- `wiki/plans/`
 - `wiki/decisions/`
 - `wiki/inbox/`
 - `wiki/meta/`

package/README.md

@@ -52,7 +52,7 @@ Project Librarian gives agents two local sources of truth:
 | Surface | What It Gives The Agent |
 | --- | --- |
 | `wiki/startup.md` + `wiki/index.md` | A compact session-start summary and router, so only the relevant planning pages are read. |
-| `wiki/canonical/` and `wiki/decisions/` | Current project facts, constraints, risks, package contracts, CLI behavior, and durable decisions. |
+| `wiki/canonical/`, `wiki/roadmaps/`, `wiki/plans/`, and `wiki/decisions/` | Current truth stays in canonical pages, broad future work stays in roadmaps, detailed execution stays in plans, and durable rationale stays in decisions. |
 | `wiki/meta/document-taxonomy.md` | A service-lifecycle classification map that tells agents where PRD, policy, UX, data, engineering, QA, release, and operations truth should live. |
 | `.codex/`, `.claude/`, `.cursor/`, and `.gemini/` hooks | Automatic startup context for Codex, Claude Code, Cursor, and Gemini CLI without loading the full wiki. |
 | `GEMINI.md` and `.cursor/rules/` | Gemini CLI and Cursor instruction files that route agents to the same compact wiki-first contract. |
@@ -236,6 +236,8 @@ Git hook files:
 Wiki directories:
 
 - `wiki/canonical/`
+- `wiki/roadmaps/`
+- `wiki/plans/`
 - `wiki/decisions/`
 - `wiki/inbox/`
 - `wiki/meta/`

package/SKILL.md

@@ -200,6 +200,7 @@ Execution contract:
 3. Separate evidence mapping from canonical truth:
    - Code structure, entrypoints, module relationships, execution flows, read-on-demand routes, and evidence paths belong under `wiki/meta/` with descriptive project-specific filenames chosen by the LLM.
    - Code-backed current project behavior, features, policies, constraints, terminology, domain rules, and operational facts belong under `wiki/canonical/`.
+   - Broad future work belongs under `wiki/roadmaps/`; detailed execution plans belong under `wiki/plans/`. After completion, update canonical truth and remove completed roadmap/plan content after rationale and evidence are preserved.
    - Important design rationale or tradeoffs inferred from code may belong under `wiki/decisions/` when they meet the decision policy.
    - Unclear, conflicting, or low-confidence interpretations belong in `wiki/inbox/` or a focused canonical questions page created for the topic, not directly in canonical truth.
 4. Do not use fixed canonical filenames. Choose or create files from topic boundaries, expected read frequency, and token budget.
@@ -228,6 +229,8 @@ It installs:
 - `wiki/startup.md` compact session-start context.
 - `wiki/index.md` router with read/update/token-budget hints.
 - `wiki/canonical/` directory for project-current-truth documents, created only when real content exists.
+- `wiki/roadmaps/` for broad future scope and priority queues, created only when real content exists.
+- `wiki/plans/` for detailed future execution plans, created only when real content exists.
 - Optional `wiki/canonical/glossary.md` project terminology contract when `--glossary-init` is used.
 - `wiki/decisions/` project-decision directory and lightweight decision ledgers.
 - `wiki/meta/` wiki operating rules, project decision policy, and wiki-operations Decision Pack.
@@ -247,7 +250,7 @@ Project canonical wiki content should not default to Korean or English. Choose t
 
 ## Boundary Rule
 
-`wiki/canonical/` and `wiki/decisions/` are for project planning only. Do not store wiki operating decisions, hook/bootstrap/lint/migration details, LLM collaboration preferences, assistant reminders, or non-project workflow memory there.
+`wiki/canonical/`, `wiki/roadmaps/`, `wiki/plans/`, and `wiki/decisions/` are for project planning only. Do not store wiki operating decisions, hook/bootstrap/lint/migration details, LLM collaboration preferences, assistant reminders, or non-project workflow memory there.
 
 Use:
 
@@ -255,6 +258,8 @@ Use:
 - Root `AGENTS.md`, hooks, or skills for durable project-wide LLM instructions and collaboration memory.
 - `wiki/AGENTS.md` for wiki-internal editing rules that should apply only under `wiki/`.
 - `wiki/canonical/` only for current project truth.
+- `wiki/roadmaps/` only for broad future scope, priority queues, and milestone sequences.
+- `wiki/plans/` only for detailed future execution plans.
 - `wiki/decisions/` only for project decision history.
 
 Every wiki markdown file should include a compact metadata header with `status`, `updated`, `scope`, `read_budget`, `decision_ref`, and `review_trigger`.

package/dist/templates.js

@@ -70,7 +70,7 @@ At the start of every session:
 
 1. Review \`wiki/startup.md\` for compact current context.
 2. Review \`wiki/index.md\` as the router for which files to read next.
-3. Read detailed \`wiki/canonical/\`, \`wiki/decisions/\`, \`wiki/meta/\`, and \`wiki/sources/\` files on demand only when the current question needs them.
+3. Read detailed \`wiki/canonical/\`, \`wiki/roadmaps/\`, \`wiki/plans/\`, \`wiki/decisions/\`, \`wiki/meta/\`, and \`wiki/sources/\` files on demand only when the current question needs them.
 
 ### ${exports.startupTldrSyncLabel}
 
@@ -133,12 +133,14 @@ Language policy:
 Reading rules:
 
 - Treat \`startup.md\` as compact session context and \`index.md\` as the router.
-- Read detailed \`canonical/\`, \`decisions/\`, \`meta/\`, and \`sources/\` files on demand only when the current question needs them.
+- Read detailed \`canonical/\`, \`roadmaps/\`, \`plans/\`, \`decisions/\`, \`meta/\`, and \`sources/\` files on demand only when the current question needs them.
 - Prefer each file's TL;DR and metadata before reading the full body.
 
 Storage boundaries:
 
 - \`canonical/\` contains current project-planning truth only.
+- \`roadmaps/\` contains broad future scope, priority queues, and milestone sequences only; it is not canonical truth.
+- \`plans/\` contains detailed execution plans for roadmap items only; it is not canonical truth.
 - \`decisions/\` contains project decision history only.
 - \`meta/\` contains wiki operating rules, decision policy, bootstrap, lint, hook, and migration decisions.
 - \`sources/\` contains external reference summaries and source notes.
@@ -150,6 +152,8 @@ Classification rules:
 
 - Before adding or consolidating project content, classify it with \`meta/document-taxonomy.md\`.
 - Write current agreement to the narrowest durable canonical document that fits the taxonomy; do not append unrelated material to \`canonical/project-brief.md\`.
+- Put broad future work in \`roadmaps/\` and detailed execution plans in \`plans/\`, not \`canonical/\`.
+- When roadmap or plan work is completed, update canonical truth first, preserve rationale/evidence where needed, then remove the completed roadmap/plan content.
 - If one input crosses several lifecycle areas, split it into separate canonical updates and link the related pages.
 - If the input explains why a direction changed, update the relevant decision log or Decision Pack in addition to canonical truth.
 - If an external artifact is the better source of truth (for example Figma, OpenAPI, ERD, issue tracker, or code), keep a concise canonical summary and link the external source as the authoritative location.
@@ -187,10 +191,11 @@ exports.startup = `${(0, exports.metadata)("startup-router", "short", "wiki/meta
 ## TL;DR
 
 - This project is in an initial planning state unless the canonical wiki says otherwise.
-- Project truth lives in \`wiki/canonical/\`, project decision history lives in \`wiki/decisions/\`, and source summaries live in \`wiki/sources/\`.
+- Project truth lives in \`wiki/canonical/\`, future work in \`wiki/roadmaps/\` and \`wiki/plans/\`, project decisions in \`wiki/decisions/\`, and sources in \`wiki/sources/\`.
 - Wiki operating rules and wiki operating decisions live in \`wiki/meta/\`.
 - At session start, read only this file and \`wiki/index.md\` first; read detailed files on demand.
 - Project canonical content language is not fixed by this bootstrap. The LLM should choose the language that best matches the user and project context.
+- Completed roadmaps/plans are removed after truth/rationale/evidence capture.
 - Update the wiki in the same turn when project-planning content changes.
 - Classify new project-planning content with \`wiki/meta/document-taxonomy.md\` before writing or consolidating it.
 
@@ -239,7 +244,9 @@ This file is a router, not a file to expand into every answer. Read only the fil
 
 ## Boundary Rule
 
-- \`wiki/canonical/\` and \`wiki/decisions/\` contain project-planning content only.
+- \`wiki/canonical/\`: current accepted project truth only.
+- \`wiki/roadmaps/\`: broad future scope only; \`wiki/plans/\`: detailed execution only.
+- \`wiki/decisions/\`: project decision history only.
 - Wiki operating rules and wiki operating decisions live in \`wiki/meta/\`.
 - Non-project LLM memory, collaboration reminders, and workflow instructions belong in \`AGENTS.md\`, \`wiki/AGENTS.md\`, hooks, or skills, not in project canonical/decision docs.
 
@@ -254,7 +261,7 @@ This file is a router, not a file to expand into every answer. Read only the fil
 
 No empty canonical starter pages are created by default. Create focused pages under \`wiki/canonical/\` only when durable project truth exists, then route them here or with \`--refresh-index\`.
 
-## Project Decisions
+## Decisions
 
 - [[decisions/recent]]
   - Read: recent important project decisions.
@@ -335,6 +342,7 @@ exports.wikiOperatingModel = `${(0, exports.metadata)("wiki-meta", "medium", "wi
 - This wiki keeps project-planning knowledge as durable markdown.
 - Codex, Claude Code, Cursor, and Gemini CLI session-start hooks inject only \`wiki/startup.md\` and \`wiki/index.md\`.
 - Detailed canonical and decision files are read on demand.
+- Roadmaps and plans are separate from canonical truth; canonical pages keep the current accepted state.
 - Root \`AGENTS.md\` keeps the project-wide wiki-first contract; \`wiki/AGENTS.md\` keeps detailed wiki editing rules.
 - Operating documents generated by bootstrap are English by default.
 - Project canonical content language is selected from user/project context, not hardcoded by this bootstrap.
@@ -352,24 +360,28 @@ Karpathy's LLM Wiki pattern favors a continuously maintained markdown wiki over
 ## Layers
 
 1. Sources: external docs, links, user notes, and evidence summaries.
-2. Canonical project truth: current valid planning content under \`wiki/canonical/\`.
-3. Project decisions: rationale, rejected alternatives, and revisit triggers under \`wiki/decisions/\`.
-4. Startup context: compact session summary in \`wiki/startup.md\`.
-5. Router: read/update/token-budget guidance in \`wiki/index.md\`.
-6. Wiki meta: operating rules, decision policy, bootstrap, migration, lint, and language policy under \`wiki/meta/\`.
+2. Canonical project truth: current accepted specs, contracts, policies, and operating state under \`wiki/canonical/\`.
+3. Roadmaps: broad future scope, priority queues, and milestone sequences under \`wiki/roadmaps/\` or an external tracker.
+4. Plans: detailed execution plans for roadmap items under \`wiki/plans/\` or an external tracker.
+5. Project decisions: rationale, rejected alternatives, and revisit triggers under \`wiki/decisions/\`.
+6. Startup context: compact session summary in \`wiki/startup.md\`.
+7. Router: read/update/token-budget guidance in \`wiki/index.md\`.
+8. Wiki meta: operating rules, decision policy, bootstrap, migration, lint, and language policy under \`wiki/meta/\`.
 
 ## Content Classification Procedure
 
 Before writing or reorganizing project-planning content:
 
 1. Identify the content's lifecycle area with [[meta/document-taxonomy]].
-2. Decide whether the content is current truth, decision rationale, source evidence, an unresolved candidate, or a wiki operating rule.
-3. Write current truth to the narrowest relevant \`canonical/\` page, decision rationale to \`decisions/\`, source notes to \`sources/\`, candidates to \`inbox/\`, and wiki operating rules to \`meta/\`.
+2. Decide whether the content is current truth, roadmap, detailed plan, decision rationale, source evidence, an unresolved candidate, or a wiki operating rule.
+3. Write current truth to the narrowest relevant \`canonical/\` page, broad future scope to \`roadmaps/\`, detailed execution plans to \`plans/\`, decision rationale to \`decisions/\`, source notes to \`sources/\`, candidates to \`inbox/\`, and wiki operating rules to \`meta/\`.
 4. Split multi-area inputs instead of making one catch-all document.
 5. Link upstream and downstream pages when the content derives from another artifact or produces another artifact.
 
 Do not treat \`canonical/project-brief.md\` as a default dumping ground. It should summarize direction, audience, scope, and success criteria; detailed product, policy, UX, data, engineering, QA, release, or operations truth should move into focused pages when it grows.
 
+Do not treat \`wiki/canonical/\` as a plan archive. If a whole document is mainly about future scope, implementation sequence, migration wave, branch status, or work result log, keep it outside canonical truth and link it from the relevant current-spec page only when readers need that context. When the work is done, update canonical truth and then remove completed roadmap/plan content after rationale and evidence are preserved in their proper places.
+
 ## Language Policy
 
 - Bootstrap-generated operating documents are English.
@@ -448,14 +460,15 @@ exports.documentTaxonomy = `${(0, exports.metadata)("wiki-meta", "medium", "wiki
 ## TL;DR
 
 - Classify new project-planning content before writing it into the wiki.
-- Use this page to classify content into \`canonical/\`, \`decisions/\`, \`sources/\`, \`inbox/\`, or \`meta/\`.
-- Keep \`canonical/project-brief.md\` compact; move detailed truth into focused canonical pages.
+- Classify into \`canonical/\`, \`roadmaps/\`, \`plans/\`, \`decisions/\`, \`sources/\`, \`inbox/\`, or \`meta/\`.
+- Keep \`canonical/project-brief.md\` compact; move details into focused pages.
+- Keep future work outside canonical; canonical pages may include brief change pointers.
 - Preserve derivation links: evidence -> strategy -> requirements -> design/data/engineering -> QA -> release/operations -> feedback.
 
 ## Top-Level Flow
 
 \`\`\`text
-0. Source-of-truth governance
+0. Governance
   -> 1. Research and evidence
     -> 2. Strategy and business model
       -> 3. Product scope and requirements
@@ -469,27 +482,37 @@ exports.documentTaxonomy = `${(0, exports.metadata)("wiki-meta", "medium", "wiki
             -> 11. Release and operations
               -> 12. Business operations
                 -> 13. Improvement, migration, and end-of-life
-                  -> next product scope, policy, or roadmap change
+                  -> roadmap -> plan -> canonical update
 \`\`\`
 
 ## Storage Decision
 
 | Content Type | Store In | Notes |
 | --- | --- | --- |
-| Current valid project truth | \`wiki/canonical/\` | Split by topic and read frequency. |
+| Current project truth | \`wiki/canonical/\` | Accepted spec, contract, policy, or operating state. |
+| Roadmap, milestone sequence, or priority queue | \`wiki/roadmaps/\` or tracker | Broad future scope, not canonical truth. |
+| Detailed plan, proposal, migration, or task sequence | \`wiki/plans/\` or external tracker | Execution detail, not canonical truth. |
 | Why a choice was made | \`wiki/decisions/\` | Use log, Decision Pack, or ADR by impact. |
 | Source material or summarized evidence | \`wiki/sources/\` | Keep links, checked dates, and applicability. |
 | Unreviewed or ambiguous material | \`wiki/inbox/\` | Do not treat as canonical truth. |
 | Wiki operation, taxonomy, hooks, migration, lint, language rules | \`wiki/meta/\` | Keep outside project canonical truth. |
 | Better external source of truth | External artifact plus a concise wiki route | Examples: Figma, OpenAPI, ERD, Jira, code. |
 
+## Canonical vs Roadmap vs Plan Boundary
+
+\`wiki/canonical/\` is for the state readers should treat as true now. A page mainly about future change, implementation sequence, migration wave, branch status, or work log is not canonical truth.
+
+Use \`wiki/roadmaps/\` for broad ordered future work. Use \`wiki/plans/\` for one roadmap item's details. Put only short planned-change notes in canonical pages.
+
+After acceptance or release, rewrite canonical truth. Move rationale to \`wiki/decisions/\` and evidence to \`wiki/sources/\`, release notes, or reports. Then delete completed roadmap/plan content unless external retention is required.
+
 ## Lifecycle Areas
 
 | Area | Put Here | Usually Derives From | Usually Produces |
 | --- | --- | --- | --- |
 | 0. Governance | source-of-truth map, owners, RACI, approval flow, change rules, glossary, state dictionary, assumptions, risk register | team/process constraints | routing, ownership, conflict resolution |
 | 1. Research | market, competitor, user interviews, VOC, analytics, legal/regulatory, technical feasibility, cost, vendor, accessibility research | raw discovery | strategy, risks, sources |
-| 2. Strategy | service overview, vision, problem, target users, personas, jobs-to-be-done, value offer, positioning, business model, KPI/OKR, success/stop criteria, roadmap, MVP, non-goals | research | PRD, roadmap, scope |
+| 2. Strategy | service overview, vision, problem, target users, personas, jobs-to-be-done, value offer, positioning, business model, KPI/OKR, success/stop criteria, committed roadmap summary, MVP, non-goals | research | PRD, roadmap, scope |
 | 3. Product | PRD, user stories, use cases, priorities, backlog rules, acceptance criteria, feature spec, exceptions, state definitions, notification rules, search/filter/sort rules, admin requirements | strategy and policy | UX, API, data, QA |
 | 4. Policy | operations policy, auth/account, permissions, pricing, payment/refund, coupon/credit, content moderation, notifications, retention/deletion, abuse response, support, EOL | business model, law, risks | feature constraints, API rules, CS/ops |
 | 5. UX and Content | IA, sitemap, user flow, task flow, screen list, wireframes, screen specs, content model, UX writing, empty/error states, help/FAQ, localization, SEO, accessibility criteria | product and policy | design, frontend, QA |
@@ -498,7 +521,7 @@ exports.documentTaxonomy = `${(0, exports.metadata)("wiki-meta", "medium", "wiki
 | 8. Engineering | architecture, technology decisions, API/OpenAPI, integrations, webhooks/idempotency, state machines, jobs/cron, error codes, env vars, secrets, local dev, conventions, branch/release strategy, CI/CD, feature flags, dependencies, migrations, performance, scalability, FinOps | product, UX, data, policy | implementation and verification |
 | 9. Security/Legal | security requirements, threat model, privacy rules, privacy impact, terms, privacy policy, audit logs, permission history, internal access controls, key rotation, vulnerability response, licenses, vendor and DPA documents | data, architecture, law | controls, tests, release gates |
 | 10. QA | test strategy, QA scenarios, test cases, regression checklist, UAT, browser/device matrix, accessibility tests, performance tests, security tests, data quality tests, design QA, quality gates | requirements, design, engineering | release approval |
-| 11. Release/Ops | release plan, deployment procedure, rollback, release notes, operator manual, runbooks, monitoring, observability, SLO/SLA, on-call/escalation, incident response, backup/restore, DR/BCP, recurring checks | QA and infrastructure | stable operation |
+| 11. Release/Ops | current release policy, deployment procedure, rollback, release notes, operator manual, runbooks, monitoring, observability, SLO/SLA, on-call/escalation, incident response, backup/restore, DR/BCP, recurring checks | QA and infrastructure | stable operation |
 | 12. Business Ops | CS macros, support policy, training, sales/adoption guide, CRM rules, onboarding playbook, churn/offboarding, admin operations, communication templates, revenue recognition, tax/invoice, partner operations | policy, release, sales motion | customer-facing operation |
 | 13. Improvement/EOL | VOC summary, retrospectives, experiments, experiment results, cohort/retention analysis, feature deprecation, migration/data transfer, service end-of-life | operations and analytics | next PRD, policy, roadmap |
 
@@ -507,11 +530,14 @@ exports.documentTaxonomy = `${(0, exports.metadata)("wiki-meta", "medium", "wiki
 When a new note arrives:
 
 1. Identify the lifecycle area and storage location.
-2. Update an existing focused page when the topic already has a canonical home.
-3. Create a new focused page only when the topic is durable, likely to be read independently, or too large for its current page.
-4. Add an \`index.md\` route when the page becomes durable.
-5. Add upstream/downstream links in prose or tables when one artifact derives from another.
-6. Record decision rationale separately when the change explains why the project chose one option over another.
+2. Decide whether content is current truth, roadmap, plan, decision rationale, evidence, candidate, or wiki operating rule.
+3. Update an existing focused canonical page only when the content changes current truth.
+4. Create a new focused page only when the topic is durable, likely to be read independently, or too large for its current page.
+5. If the document is future-oriented, store broad scope in \`roadmaps/\` and detailed execution in \`plans/\`.
+6. Add an \`index.md\` route when the page becomes durable.
+7. Add upstream/downstream links in prose or tables when one artifact derives from another.
+8. Record decision rationale separately when the change explains why the project chose one option over another.
+9. When roadmap/plan work is done, update canonical truth, preserve rationale/evidence, then remove completed roadmap/plan content.
 
 ## Page Shape
 
@@ -670,7 +696,7 @@ No project decisions yet.
 ## TL;DR
 
 - This Decision Pack records accepted wiki operating choices for project-librarian.
-- It covers wiki structure, document taxonomy, startup hook scope, metadata, language policy, git hook behavior, migration review, and inbox handling.
+- It covers wiki structure, document taxonomy, startup hook scope, metadata, language policy, git hook behavior, migration review, inbox handling, and canonical/roadmap/plan boundaries.
 - Project product decisions belong in \`wiki/decisions/\`, while these operating decisions stay in \`wiki/meta/\`.
 
 Status: accepted
@@ -685,6 +711,8 @@ Canonical: [[meta/operating-model]], [[meta/decision-policy]], [[meta/document-t
 | ${workspace_1.today} | Inject only \`startup.md\` and \`index.md\` through Codex, Claude Code, Cursor, and Gemini CLI startup hooks; route detailed files Read On Demand. | Full canonical and decision bodies waste startup tokens. | Always read detailed canonical and decision files first. | Important context is repeatedly missed at startup. | [[startup]], [[index]] |
 | ${workspace_1.today} | Use metadata headers on wiki knowledge pages. | Agents and humans can quickly judge status, scope, budget, and review triggers. | Body-only conventions. | Header maintenance costs more than it saves. | [[meta/operating-model]] |
 | ${workspace_1.today} | Keep wiki operating docs in \`wiki/meta/\`. | Project truth stays focused on product/project content. | Store operating docs in \`canonical/\` or \`decisions/\`. | Meta docs become hard to discover. | [[meta/operating-model]] |
+| ${workspace_1.today} | Split future work into \`roadmaps/\` and \`plans/\`, outside canonical truth. | Roadmaps list broad future scope and sequencing; plans describe detailed execution for one roadmap item; canonical pages should show only the current accepted spec, contract, policy, or operating state. | Store roadmap, improvement, migration, and implementation plans directly in \`canonical/\` as if they were current truth, or mix roadmaps and detailed plans in one directory. | Teams need a different planning directory convention, or plan artifacts become the authoritative source for current behavior. | [[meta/document-taxonomy]], [[meta/operating-model]] |
+| ${workspace_1.today} | Remove completed roadmap and plan content after canonical truth, rationale, and evidence are updated. | Completed future-work documents become stale logs once their outcome is reflected in canonical pages, decisions, and evidence artifacts. | Keep completed roadmap/plan documents indefinitely inside the wiki. | Audit, legal, or release process requires retaining completed plan artifacts in a dedicated external system. | [[meta/document-taxonomy]], [[meta/operating-model]] |
 | ${workspace_1.today} | Bootstrap-generated operating documents are English by default. | Repository entry points and operating contracts are easier for public users to inspect. | Generate operating docs in a fixed non-English language. | The project intentionally targets a single-language local audience. | [[meta/operating-model]] |
 | ${workspace_1.today} | Project canonical content language is chosen from user/project context. | User language and source material should drive project truth, not the bootstrap tool. | Hardcode Korean or English as the canonical content language. | A team requires a fixed language policy. | [[startup]], [[index]] |
 | ${workspace_1.today} | Install git hook files but preserve existing \`core.hooksPath\` values and allow \`--no-git-config\`. | Public users may already have a hook chain such as Husky. | Always replace \`core.hooksPath\`. | Users prefer automatic setup and accept the side effect. | [[meta/operating-model]] |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "project-librarian",
-  "version": "0.4.2",
+  "version": "0.4.3",
   "description": "Create and maintain compact project context for humans and LLM coding agents.",
   "license": "MIT",
   "type": "commonjs",