ai-ops-cli 1.2.0 → 1.3.1

package/data/skills/task-skills/{spec-shared-glossary-sync → project-terminology-sync}/SKILL.md

@@ -1,12 +1,12 @@
 ---
-name: spec-shared-glossary-sync
-description: Create or update a Korean 01_glossary.md inside the current project's docs/specs/baseline directory by standardizing domain terms, entities, states, UI labels, and English code-facing names across baseline docs and active .codex/plans.
+name: project-terminology-sync
+description: Create or update the current project's docs/business/terminology.md by standardizing project-wide domain terms, entities, states, UI labels, and English code-facing names across business docs, specs, active .codex/plans, and work packets.
 disable-model-invocation: true
 ---
 
-# spec-shared-glossary-sync
+# project-terminology-sync
 
-Use this skill when the project needs a shared glossary or when existing docs/specs/plans have begun to drift in terminology.
+Use this skill when the project needs canonical terminology or when existing business docs, specs, plans, or packets have begun to drift in terminology.
 
 Typical high-value run points are:
 
@@ -14,6 +14,7 @@ Typical high-value run points are:
 - after `product spec`
 - after `ui spec`
 - during `spec-baseline-sync` if implemented terminology changed
+- after business rule changes introduce new domain language
 - whenever naming drift is noticed
 
 Usually skip automatic reruns after small plans unless new shared terminology was introduced.
@@ -21,18 +22,18 @@ Usually skip automatic reruns after small plans unless new shared terminology wa
 ## Output Location
 
 - Write into the current workspace.
-- Default output path: `./docs/specs/baseline/01_glossary.md`
+- Default output path: `./docs/business/terminology.md`
 
 ## Language Rules
 
-- Write the glossary in Korean.
+- Write terminology content in Korean.
 - Keep code-facing English identifiers, API field names, library/service names, protocol names, file paths, and standard technical terms in their natural English form when clearer.
 - Do not invent awkward Koreanized spellings for standard English technical terms.
 - If a term needs explanation, keep the standard term and add a short Korean definition.
 
 ## Objective
 
-Maintain one canonical vocabulary so briefs, specs, UI docs, plans, packets, and baseline sync entries use the same terms for the same concepts.
+Maintain one canonical project vocabulary so business docs, briefs, specs, UI docs, plans, packets, and baseline sync entries use the same terms for the same concepts.
 
 The default output style is:
 
@@ -42,10 +43,14 @@ The default output style is:
 
 ## Create Or Update Rules
 
-- If `./docs/specs/baseline/01_glossary.md` does not exist, create it from currently approved specs and relevant active plans.
+- If `./docs/business/terminology.md` does not exist, create it with operating-layer frontmatter from `references/template.md`.
 - If it exists, update it instead of replacing it blindly.
+- Preserve existing frontmatter unless the document is being promoted from `Reserved` to `Active`.
+- When the document receives real terminology content, set frontmatter `status: Active`.
+- If `docs/docs-status.md` exists, update the `docs/business/terminology.md` row to match the frontmatter status and owner.
+- If `.ai-ops/context-layer.json` exists, update the `docs/business/terminology.md` entry so status, read/update conditions, and content hash match the file.
 - Preserve stable canonical terms unless there is a strong reason to change them.
-- If a newly found term conflicts with an existing definition, keep the current canonical term and record the conflict in `정의 충돌 / 검토 필요`.
+- If a newly found term conflicts with an existing definition, keep the current canonical term and record the conflict in `검토 중인 용어`.
 - Normalize synonyms toward one preferred term.
 - Prefer Korean for user-facing/domain wording, but keep standard English when clearer, more stable, or already established in the project.
 
@@ -53,13 +58,14 @@ The default output style is:
 
 Read relevant files that exist:
 
+- `./docs/business/terminology.md`
+- `./docs/business/business-rules.md`
 - `./docs/specs/baseline/00_brief.md`
 - `./docs/specs/baseline/05_technical-context.md`
 - `./docs/specs/baseline/10_product-spec.md`
 - `./docs/specs/baseline/20_ui-spec.md`
 - active `./.codex/plans/*.md` when terminology from a current change needs to become canonical
 - `./docs/specs/initial-build/<topic>/30_work-packets/*.md` when reviewing initial build terminology
-- existing `./docs/specs/baseline/01_glossary.md`
 
 Use only files that are present and relevant.
 
@@ -71,9 +77,11 @@ Use only files that are present and relevant.
 4. Attach English code-facing counterpart when needed.
 5. Capture harmless synonyms only when useful.
 6. List discouraged or banned wording when ambiguity is likely.
-7. Write most glossary content as tables.
-8. Move only hard cases into detailed sections.
-9. Update the glossary without deleting still-valid prior decisions.
+7. Promote `docs/business/terminology.md` from `Reserved` to `Active` if real terminology is written.
+8. Write most terminology content as tables.
+9. Move only hard cases into detailed sections.
+10. Update `docs/docs-status.md` and `.ai-ops/context-layer.json` when they exist.
+11. Update terminology without deleting still-valid prior decisions.
 
 Use these references while drafting:
 
@@ -87,13 +95,14 @@ Use these references while drafting:
 - `상태 용어`
 - `UI 용어`
 - `금지하거나 피할 표현`
-- `복잡한 개념 상세 설명`
-- `정의 충돌 / 검토 필요`
+- `검토 중인 용어`
 
 ## Quality Bar
 
-The glossary is not ready if:
+The terminology document is not ready if:
 
+- frontmatter is missing or the document has real terminology but still says `status: Reserved`
+- `docs/docs-status.md` or `.ai-ops/context-layer.json` disagree with the terminology document status when those files exist
 - simple vocabulary that should be in tables is expanded into unnecessary prose
 - the same concept still appears under multiple primary names
 - terms are listed without definitions

package/data/skills/task-skills/project-terminology-sync/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "project-terminology-sync"
+  short_description: "Standardize project terms into docs/business/terminology.md."
+  default_prompt: "Use $project-terminology-sync to create or update docs/business/terminology.md, standardizing project-wide terms across business docs, specs, active .codex/plans, and work packets."
+policy:
+  allow_implicit_invocation: false

package/data/skills/task-skills/{spec-shared-glossary-sync → project-terminology-sync}/references/checklist.md

@@ -1,6 +1,6 @@
-# Glossary Sync Checklist
+# Project Terminology Sync Checklist
 
-Use this checklist before finalizing `01_glossary.md`.
+Use this checklist before finalizing `docs/business/terminology.md`.
 
 ## Look For
 
@@ -30,7 +30,7 @@ Use this checklist before finalizing `01_glossary.md`.
 
 ## Update Rule
 
-- merge new terms into the existing glossary
+- merge new terms into the existing terminology document
 - do not delete stable terms unless they are clearly wrong
-- when uncertain, add the conflict to `정의 충돌 / 검토 필요`
-- keep simple terms in tables; avoid turning the whole glossary into long prose
+- when uncertain, add the conflict to `검토 중인 용어`
+- keep simple terms in tables; avoid turning the whole terminology document into long prose

package/data/skills/task-skills/{spec-shared-glossary-sync → project-terminology-sync}/references/template.md

@@ -1,7 +1,20 @@
-# 01_glossary.md Template
+# docs/business/terminology.md Template
 
 ```md
-# 01 Glossary
+---
+status: Active
+layer: business
+owner: project
+read_when:
+  - terminology_check
+  - business_rule_check
+  - spec_lifecycle
+update_when:
+  - terminology_changes
+  - business_rule_changes
+  - spec_lifecycle_changes
+---
+# Terminology
 
 용어 표기 원칙:
 
@@ -38,21 +51,9 @@
 |---|---|---|
 | 표현 1 | 왜 피해야 하는지 | 표준 표현 |
 
-## 복잡한 개념 상세 설명
+## 검토 중인 용어
 
-### 개념 1
-
-- 왜 이 개념이 표만으로는 충분하지 않은지 설명
-- 어떤 문맥에서 다른 표현과 충돌하는지 설명
-
-```mermaid
-flowchart TD
-    A["개념 A"] --> B["개념 B"]
-```
-
-## 정의 충돌 / 검토 필요
-
-| 항목 | 현재 표준 | 충돌 표현 | 판단 메모 |
-|---|---|---|---|
-| 충돌 항목 | 현재 표준 표현 | 새로 발견된 표현 | 판단 메모 |
+| 항목 | 후보 표현 | 충돌 / 불확실성 | 판단 메모 | 관련 문서 |
+|---|---|---|---|---|
+| 충돌 항목 | 새로 발견된 표현 | 현재 표준 표현과의 차이 | 판단 메모 | `10_product-spec.md` |
 ```

package/data/skills/task-skills/spec-baseline-sync/SKILL.md

@@ -10,7 +10,7 @@ Use this skill after a post-MVP change has been implemented and verified, and th
 
 ## Output Location
 
-- Update only affected files under `./docs/specs/baseline/`.
+- Update only affected files under `./docs/specs/baseline/` and `./docs/business/terminology.md` when project terminology changed.
 - Move the completed plan from `./.codex/plans/<plan>.md` to `./.codex/plans/archived/YYYY-MM/<plan>.md`.
 - Append a compact entry to `./.codex/CHANGE_LOG.md`.
 
@@ -31,7 +31,7 @@ Read the relevant available inputs before updating baseline:
 2. implemented code changes, PR diff, commit diff, or implementation notes
 3. verification results and known skipped tests
 4. optional issue or PR link
-5. existing `./docs/specs/baseline/01_glossary.md`
+5. existing `./docs/business/terminology.md`
 6. existing `./docs/specs/baseline/05_technical-context.md`
 7. existing `./docs/specs/baseline/10_product-spec.md`
 8. existing `./docs/specs/baseline/20_ui-spec.md`
@@ -64,7 +64,7 @@ Baseline sync is implementation-confirming work.
 
 1. Identify the plan being closed and the implementation evidence.
 2. Compare shipped behavior against current baseline docs.
-3. Decide which baseline docs are affected among `01,05,10,20,22,24`.
+3. Decide whether project terminology or baseline docs among `05,10,20,22,24` are affected.
 4. Update only affected baseline docs while preserving still-valid prior decisions.
 5. Append one changelog entry summarizing what changed, why, evidence, baseline impact, and follow-up.
 6. Move the plan into `.codex/plans/archived/YYYY-MM/`.
@@ -74,7 +74,7 @@ Use [references/template.md](references/template.md) for the changelog entry sha
 
 ## Baseline Update Rules
 
-- `./docs/specs/baseline/01_glossary.md`: update only when the implementation introduced or normalized meaningful shared terms.
+- `./docs/business/terminology.md`: update only when the implementation introduced or normalized meaningful shared terms.
 - `./docs/specs/baseline/05_technical-context.md`: update only when architecture, stack, boundaries, integrations, or deployment assumptions changed materially.
 - `./docs/specs/baseline/10_product-spec.md`: update for implemented user-flow, feature, entity, rule, edge-case, or success-criteria changes.
 - `./docs/specs/baseline/20_ui-spec.md`: update for implemented screens, states, interactions, or UI constraints.

package/data/skills/task-skills/spec-product-01-idea-to-brief/SKILL.md

@@ -20,10 +20,10 @@ Use this skill when the input is still rough and the next artifact should be `./
 - Do not force awkward phonetic transliterations such as `소스 오브 트루스`, `타겟 플랫폼`, or `워크 패킷`.
 - If an English technical term needs explanation, keep the English term and add a short Korean gloss on first mention, for example `source of truth(가장 신뢰하는 기준)`.
 
-## Glossary Rule
+## Terminology Rule
 
-- Check `./docs/specs/baseline/01_glossary.md` only if it exists and the brief introduces product terms, user-facing labels, or domain nouns that may collide with existing terminology.
-- After writing the target document, `spec-shared-glossary-sync` is recommended because briefs often introduce new canonical terms.
+- Check `./docs/business/terminology.md` if it exists and the brief introduces product terms, user-facing labels, or domain nouns that may collide with existing terminology.
+- After writing the target document, `project-terminology-sync` is recommended because briefs often introduce new canonical terms.
 
 ## Objective
 

package/data/skills/task-skills/spec-product-02-brief-to-technical-context/SKILL.md

@@ -20,10 +20,10 @@ Use this skill after `./docs/specs/baseline/00_brief.md` is approved and before
 - Do not force awkward phonetic transliterations such as `소스 오브 트루스`, `타겟 플랫폼`, or `워크 패킷`.
 - If an English technical term needs explanation, keep the English term and add a short Korean gloss on first mention, for example `source of truth(가장 신뢰하는 기준)`.
 
-## Glossary Rule
+## Terminology Rule
 
-- Check `./docs/specs/baseline/01_glossary.md` only if it exists and the document introduces stack names, architectural terms, or labels that should align with existing terminology.
-- After writing the target document, run `spec-shared-glossary-sync` only if new technical terms, product-facing labels, or collisions were introduced.
+- Check `./docs/business/terminology.md` if it exists and the document introduces stack names, architectural terms, or labels that should align with existing terminology.
+- After writing the target document, run `project-terminology-sync` only if new technical terms, product-facing labels, or collisions were introduced.
 
 ## Default Stack Preferences
 

package/data/skills/task-skills/spec-product-03-brief-to-product-spec/SKILL.md

@@ -50,10 +50,10 @@ Keep this pass lightweight and product-facing.
 
 Use [references/template.md](references/template.md) when drafting the file.
 
-## Glossary Rule
+## Terminology Rule
 
-- Check `./docs/specs/baseline/01_glossary.md` if it exists and the product spec introduces or chooses domain terms, entity names, state names, or user-facing labels.
-- After writing the target document, `spec-shared-glossary-sync` is recommended because product specs often add or refine canonical vocabulary.
+- Check `./docs/business/terminology.md` if it exists and the product spec introduces or chooses domain terms, entity names, state names, or user-facing labels.
+- After writing the target document, `project-terminology-sync` is recommended because product specs often add or refine canonical vocabulary.
 
 ## Required Sections
 

package/data/skills/task-skills/spec-product-05-spec-to-work-packets/SKILL.md

@@ -130,10 +130,10 @@ Use these references while drafting:
 - [references/work-packet-template.md](references/work-packet-template.md)
 - [references/stitch-html-review.md](references/stitch-html-review.md) only when initial Stitch HTML exists and materially helps UI packet boundaries
 
-## Glossary Rule
+## Terminology Rule
 
-- Check `./docs/specs/baseline/01_glossary.md` only if packet wording could drift from established entity, state, or UI terminology.
-- Do not run `spec-shared-glossary-sync` by default after packet generation. Run it only if packeting surfaced meaningful new terms or clear terminology collisions.
+- Check `./docs/business/terminology.md` if packet wording could drift from established entity, state, or UI terminology.
+- Do not run `project-terminology-sync` by default after packet generation. Run it only if packeting surfaced meaningful new terms or clear terminology collisions.
 
 ## Mermaid Rule