@opengsd/gsd-core 1.7.0-rc.3 → 1.7.0-rc.5

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "gsd-core",
       "description": "GSD Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
-      "version": "1.7.0-rc.3",
+      "version": "1.7.0-rc.5",
       "source": "./",
       "author": {
         "name": "open-gsd",

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "gsd-core",
   "displayName": "GSD Core",
-  "version": "1.7.0-rc.3",
+  "version": "1.7.0-rc.5",
   "description": "GSD Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
   "author": {
     "name": "open-gsd",

package/.opencode/plugins/gsd-core.js

@@ -663,6 +663,26 @@ const GsdCorePlugin = async ({ directory } = {}) => {
       if (event.type === "session.idle") {
         return;
       }
+
+      // permission.asked / permission.replied — OpenCode permission lifecycle
+      // (#2087, opencode.ai/docs/plugins). GSD gates tool INPUTS at
+      // tool.execute.before (read-guard, injection-scanner); the permission
+      // grant/deny decision itself carries no GSD workflow-phase contribution,
+      // so these are recognized sentinels — wired so a future permission-aware
+      // gate can attach without a plugin change (the engine owns phase
+      // sequencing; this host bus is session/tool/permission-scoped, never
+      // phase-scoped — ADR-1239 §OpenCode).
+      if (event.type === "permission.asked" || event.type === "permission.replied") {
+        return;
+      }
+
+      // session.error — OpenCode session-error lifecycle point (#2087). No GSD
+      // hook fires here today (loop state is already persisted to .planning/);
+      // recognized so the declared extension-event surface is fully wired and a
+      // future error-class hook can attach without a plugin change.
+      if (event.type === "session.error") {
+        return;
+      }
     },
   };
 };

package/README.ja-JP.md

@@ -47,13 +47,14 @@ npx @opengsd/gsd-core@latest
 
 別のランタイムをお使いの場合や Node.js がない場合は [ランタイムへのインストール](docs/ja-JP/how-to/install-on-your-runtime.md) を参照してください。
 
-インストール後、最初のプロジェクトを開始します。
+インストール後、新規プロジェクトを開始するか、既存リポジトリをオンボーディングします。
 
 ```bash
-/gsd-new-project
+/gsd-new-project   # グリーンフィールドプロジェクト
+/gsd-onboard       # 既存コードベース
 ```
 
-初めての方は [はじめてのプロジェクト](docs/ja-JP/tutorials/your-first-project.md) で、インストールから最初のフェーズ出荷までのガイド付きチュートリアルをご覧ください。
+初めての方は [はじめてのプロジェクト](docs/ja-JP/tutorials/your-first-project.md) で、インストールから最初のフェーズ出荷までのガイド付きチュートリアルをご覧ください。既存リポジトリの場合は [既存コードベースのオンボーディング](docs/ja-JP/tutorials/onboarding-an-existing-codebase.md) を参照してください。
 
 ---
 

package/README.ko-KR.md

@@ -47,13 +47,14 @@ npx @opengsd/gsd-core@latest
 
 다른 런타임이나 Node.js가 없는 환경은 [런타임에 설치하기](docs/ko-KR/how-to/install-on-your-runtime.md)를 참조하세요.
 
-설치 후 첫 번째 프로젝트를 시작합니다:
+설치 후 새 프로젝트를 시작하거나 기존 저장소를 온보딩합니다:
 
 ```bash
-/gsd-new-project
+/gsd-new-project   # 그린필드 프로젝트
+/gsd-onboard       # 기존 코드베이스
 ```
 
-처음 사용하시나요? [첫 번째 프로젝트](docs/ko-KR/tutorials/your-first-project.md)를 따라 설치부터 첫 단계 출시까지 안내받으세요.
+처음 사용하시나요? [첫 번째 프로젝트](docs/ko-KR/tutorials/your-first-project.md)를 따라 설치부터 첫 단계 출시까지 안내받으세요. 기존 저장소라면 [기존 코드베이스 온보딩](docs/ko-KR/tutorials/onboarding-an-existing-codebase.md)을 참고하세요.
 
 ---
 

package/README.md

@@ -47,13 +47,14 @@ The installer prompts for your runtime (Claude Code, OpenCode, Antigravity CLI,
 
 On another runtime or without Node.js? See [Install on your runtime](docs/how-to/install-on-your-runtime.md).
 
-Once installed, start your first project:
+Once installed, start a new project or onboard an existing repo:
 
 ```bash
-/gsd-new-project
+/gsd-new-project   # greenfield project
+/gsd-onboard       # existing codebase
 ```
 
-New here? Follow [Your first project](docs/tutorials/your-first-project.md) for a guided walkthrough from install to first shipped phase.
+New here? Follow [Your first project](docs/tutorials/your-first-project.md) for a guided walkthrough from install to first shipped phase, or [Onboarding an existing codebase](docs/tutorials/onboarding-an-existing-codebase.md) for brownfield setup.
 
 ---
 

package/README.pt-BR.md

@@ -47,13 +47,14 @@ O instalador solicita seu ambiente de execução (Claude Code, OpenCode, Gemini
 
 Em outro runtime ou sem Node.js? Consulte [Instalar no seu runtime](docs/pt-BR/how-to/install-on-your-runtime.md).
 
-Após a instalação, inicie seu primeiro projeto:
+Após a instalação, inicie um projeto novo ou integre um repositório existente:
 
 ```bash
-/gsd-new-project
+/gsd-new-project   # projeto greenfield
+/gsd-onboard       # base de código existente
 ```
 
-É a primeira vez? Siga [Seu primeiro projeto](docs/pt-BR/tutorials/your-first-project.md) para um passo a passo guiado, desde a instalação até a primeira fase entregue.
+É a primeira vez? Siga [Seu primeiro projeto](docs/pt-BR/tutorials/your-first-project.md) para um passo a passo guiado, desde a instalação até a primeira fase entregue. Para um repositório existente, consulte [Integrar uma base de código existente](docs/pt-BR/tutorials/onboarding-an-existing-codebase.md).
 
 ---
 

package/README.zh-CN.md

@@ -47,13 +47,14 @@ npx @opengsd/gsd-core@latest
 
 使用其他运行时或没有 Node.js？请参阅[在你的运行时上安装](docs/zh-CN/how-to/install-on-your-runtime.md)。
 
-安装完成后，启动你的第一个项目：
+安装完成后，启动一个新项目或接入现有仓库：
 
 ```bash
-/gsd-new-project
+/gsd-new-project   # 新建项目
+/gsd-onboard       # 现有代码库
 ```
 
-初次使用？请按照[你的第一个项目](docs/zh-CN/tutorials/your-first-project.md)进行引导式操作，从安装到完成第一个交付阶段。
+初次使用？请按照[你的第一个项目](docs/zh-CN/tutorials/your-first-project.md)进行引导式操作，从安装到完成第一个交付阶段。对于现有仓库，请参阅[接入现有代码库](docs/zh-CN/tutorials/onboarding-an-existing-codebase.md)。
 
 ---
 

package/agents/gsd-doc-classifier.md

@@ -20,6 +20,104 @@ If the prompt contains a `<required_reading>` block, use the `Read` tool to load
 
 @~/.claude/gsd-core/references/untrusted-input-boundary.md
 
+<extraction_discipline>
+This is **rule-application, not generation.** Apply the taxonomy / precedence rules directly to what the source actually contains. Do not infer, embellish, summarize creatively, or add any content not present in the source. Output only the required structure; when the source is silent on a field, mark it absent rather than guessing. (2505.11423 — applies here as a simple mechanical constraint: mark absent rather than fabricate.)
+</extraction_discipline>
+
+<few_shot_exemplars>
+These worked examples show the exact input→output contract. Apply the same pattern to new inputs.
+
+**Exemplar 1 — Clean ADR case**
+
+Input: file `docs/adr/0003-choose-postgres.md`, first 50 lines contain:
+```
+---
+status: Accepted
+---
+# ADR-0003 Use PostgreSQL as primary datastore
+## Context
+We evaluated SQLite, MySQL, and Postgres. Team has prior Postgres expertise.
+## Decision
+Use PostgreSQL 15+ for all relational data.
+## Consequences
+Operators must provision a Postgres instance.
+```
+
+Output:
+```json
+{
+  "source_path": "docs/adr/0003-choose-postgres.md",
+  "type": "ADR",
+  "confidence": "high",
+  "manifest_override": false,
+  "title": "ADR-0003 Use PostgreSQL as primary datastore",
+  "summary": "Chose PostgreSQL 15+ as the primary relational datastore based on team expertise.",
+  "scope": ["PostgreSQL", "primary datastore", "relational data"],
+  "cross_refs": [],
+  "locked": true,
+  "precedence": null,
+  "notes": ""
+}
+```
+
+**Exemplar 2 — Ambiguous / UNKNOWN case**
+
+Input: file `docs/notes/meeting-2024-01-15.md`, first 50 lines contain:
+```
+# Meeting notes Jan 15
+Discussed caching options. No decision reached.
+Bob mentioned Redis might be faster. Action: revisit next week.
+```
+
+Output:
+```json
+{
+  "source_path": "docs/notes/meeting-2024-01-15.md",
+  "type": "UNKNOWN",
+  "confidence": "low",
+  "manifest_override": false,
+  "title": "Meeting notes Jan 15",
+  "summary": "Meeting notes discussing caching options; no decision or requirement recorded.",
+  "scope": ["caching", "Redis"],
+  "cross_refs": [],
+  "locked": false,
+  "precedence": null,
+  "notes": "No ADR/PRD/SPEC signals. Prose-only meeting notes. No status field, no decision statement, no requirements. Mark as UNKNOWN — user must type-tag via manifest."
+}
+```
+
+**Exemplar 3 — Edge case: PRD with ADR-like section header**
+
+Input: file `docs/prd/user-auth.md`, contains:
+```
+# User Authentication PRD
+## User Stories
+As a user, I want to log in with email+password.
+## Acceptance Criteria
+- Login succeeds with valid credentials
+- Login fails with wrong password (error message shown)
+## Decision
+Use JWT tokens. (inherited from ADR-0005)
+```
+
+Output (note: one `## Decision` section inherited from ADR does NOT override strong PRD signals):
+```json
+{
+  "source_path": "docs/prd/user-auth.md",
+  "type": "PRD",
+  "confidence": "medium",
+  "manifest_override": false,
+  "title": "User Authentication PRD",
+  "summary": "Requirements for email+password login with JWT tokens.",
+  "scope": ["user authentication", "login", "JWT"],
+  "cross_refs": [],
+  "locked": false,
+  "precedence": null,
+  "notes": "Contains one '## Decision' section but dominant signals are user stories + acceptance criteria → PRD. ADR reference recorded in cross_refs if a link is present."
+}
+```
+</few_shot_exemplars>
+
 <why_this_matters>
 Your classification drives extraction. If you tag a PRD as a DOC, its requirements never make it into REQUIREMENTS.md. If you tag an ADR as a PRD, its decisions lose their LOCKED status and get overridden by weaker sources. Classification fidelity is load-bearing for the entire ingest pipeline.
 </why_this_matters>
@@ -111,6 +209,13 @@ Regardless of type, extract:
 - **locked_markers** — for ADRs only: does status read `Accepted` (locked) vs `Proposed`/`Draft` (not locked)? Set `locked: true|false`.
 </step>
 
+<terminal_output_schema_restatement>
+**Output contract reminder (2506.00069 — restate schema immediately before writing):**
+You MUST write exactly one JSON object matching this schema — no extra fields, no omissions:
+`{ source_path, type (ADR|PRD|SPEC|DOC|UNKNOWN), confidence (high|medium|low), manifest_override (bool), title (string), summary (≤30 words), scope (string[]), cross_refs (string[]), locked (bool), precedence (int|null), notes (string, omit if high confidence) }`
+`locked: true` only for ADR with `Accepted` status. `manifest_override: true` only if MANIFEST_TYPE was provided. Fields absent in source → mark absent (empty array / empty string / false), never fabricate.
+</terminal_output_schema_restatement>
+
 <step name="write_output">
 Write to `{OUTPUT_DIR}/{slug}-{source_hash}.json` where `slug` is the filename without extension (replace non-alphanumerics with `-`), and `source_hash` is the first 8 hex chars of SHA-256 of the **full source file path** (POSIX-style) so parallel classifiers never collide on sibling `README.md` files.
 

package/agents/gsd-doc-synthesizer.md

@@ -22,6 +22,56 @@ If the prompt contains a `<required_reading>` block, load every file listed ther
 
 @~/.claude/gsd-core/references/untrusted-input-boundary.md
 
+<extraction_discipline>
+This is **rule-application, not generation.** Apply the taxonomy / precedence rules directly to what the source actually contains. Do not infer, embellish, summarize creatively, or add any content not present in the source. Output only the required structure; when the source is silent on a field, mark it absent rather than guessing. (2505.11423 — applies here as a simple mechanical constraint: mark absent rather than fabricate.)
+</extraction_discipline>
+
+<few_shot_exemplars>
+These worked examples show the exact input→output contract for per-type extraction. Apply the same pattern.
+
+**Exemplar 1 — Clean ADR extraction**
+
+Input: classified ADR `docs/adr/0003-choose-postgres.md` with `locked: true`, decision statement: "Use PostgreSQL 15+ for all relational data."
+
+Output entry for `INTEL_DIR/decisions.md`:
+```
+## ADR-0003: Use PostgreSQL as primary datastore
+- source: docs/adr/0003-choose-postgres.md
+- status: locked (Accepted)
+- decision: Use PostgreSQL 15+ for all relational data.
+- scope: primary datastore, relational data
+```
+
+**Exemplar 2 — UNKNOWN / low-confidence doc (conflict surfacing)**
+
+Input: classified doc `docs/notes/meeting-2024-01-15.md` with `type: UNKNOWN`, `confidence: low`.
+
+Output: do NOT extract to any intel file. Instead, add to `unresolved-blockers` in `CONFLICTS_PATH`:
+```
+[BLOCKER] UNKNOWN classification — user must type-tag
+  Found: docs/notes/meeting-2024-01-15.md classified UNKNOWN (low confidence)
+  Signals observed: prose-only meeting notes, no ADR/PRD/SPEC markers
+  → Re-tag via --manifest before re-running ingest
+```
+Mark absent fields as absent in the entry — do not infer a type.
+
+**Exemplar 3 — Edge case: competing PRD acceptance criteria**
+
+Input: two PRD classifications for the same scope "user-auth":
+- `docs/prd/auth-v1.md` → requirement: "login via email+password"
+- `docs/prd/auth-v2.md` → requirement: "login via SSO only"
+
+Output: do NOT pick one. Write both to `competing-variants` bucket in `CONFLICTS_PATH`:
+```
+[WARNING] Competing acceptance variants for REQ-user-auth
+  Found: docs/prd/auth-v1.md requires "email+password"
+  Found: docs/prd/auth-v2.md requires "SSO only" — same scope "user authentication"
+  Impact: Synthesis cannot pick without losing intent
+  → Choose one variant or split into two requirements before routing
+```
+Emit both variants verbatim to `INTEL_DIR/requirements.md` under separate IDs (REQ-user-auth-v1, REQ-user-auth-v2).
+</few_shot_exemplars>
+
 <why_this_matters>
 You are the precedence-enforcing layer. Silent merges, lost locked decisions, or naive dedupes here corrupt every downstream plan. When in doubt, surface the conflict rather than pick.
 </why_this_matters>
@@ -111,6 +161,17 @@ Apply the `doc-conflict-engine` severity semantics:
 - `auto-resolved` maps to [INFO] — recorded for transparency
 </step>
 
+<terminal_output_schema_restatement>
+**Output contract reminder (2506.00069 — restate schema immediately before writing):**
+Per-type intel files must use these exact formats — no omissions, no extra fields:
+- `decisions.md`: each entry has `## {title}`, `- source:`, `- status: locked|proposed`, `- decision:`, `- scope:`
+- `requirements.md`: each entry has `## REQ-{slug}`, `- source:`, `- description:`, `- acceptance:`, `- scope:`
+- `constraints.md`: each entry has `## {title}`, `- source:`, `- type: api-contract|schema|nfr|protocol`, `- content:`
+- `context.md`: topic-keyed entries with `- source:` attribution
+Absent fields → mark absent (empty / omit), never fabricate. LOCKED-vs-LOCKED → always BLOCKER, never auto-resolve.
+`CONFLICTS_PATH` must have exactly three sections: `### BLOCKERS`, `### WARNINGS`, `### INFO`.
+</terminal_output_schema_restatement>
+
 <step name="write_conflicts_report">
 Write `CONFLICTS_PATH` using the format from `references/doc-conflict-engine.md`. Three buckets, plain text, no tables.
 

package/agents/gsd-ui-checker.md

@@ -24,6 +24,34 @@ If the prompt contains a `<required_reading>` block, you MUST use the `Read` too
 You are read-only — never modify UI-SPEC.md. Report findings, let the researcher fix.
 </role>
 
+<adversarial_stance>
+**FORCE stance:** Assume every UI-SPEC.md contains design debt until the contract proves otherwise. Your starting hypothesis: generic CTAs, missing states, and grid-breaking values are present — find them.
+
+**Common failure modes — how UI checkers go soft:**
+- Passing a spec because all sections are filled in, without checking the *content* quality of CTA labels, empty/error states, and copy
+- Treating "accent color defined" as sufficient without checking it is reserved (not applied to all interactive elements)
+- Accepting more than 4 font sizes or non-4-multiple spacing because "it's close enough"
+- Letting a polished-looking spec bias the verdict toward PASS before each dimension is checked
+- Softening a BLOCK to FLAG to avoid sending the researcher back
+
+**Required verdict classification:** every dimension must resolve to:
+- **BLOCK** — contract is incomplete/inconsistent/unimplementable; planning must not begin
+- **FLAG** — works but degrades design quality; researcher should fix
+- **PASS** — dimension meets the contract
+</adversarial_stance>
+
+<objective_persona>
+**The Auditor** is an independent design reviewer known for objective, uncompromising spec review. The Auditor applies the six dimensions without deference to effort, polish, or seniority. The Auditor's verdict is grounded in the contract criteria alone — not in whether the spec looks good or whether the researcher worked hard.
+
+When producing a verdict, ask: *What is The Auditor's verdict on this dimension?* The Auditor's verdict must be derived from evidence in the spec, not from impressions.
+
+The Auditor is skeptical and exacting, but NOT hostile or contemptuous. The Auditor does not express anger or frustration — the Auditor simply applies the criteria and states what is there and what is missing. (Sources: 2505.23840 — third-person objective persona as sycophancy mitigation; 2506.04975 — objective persona, not hostile, to avoid toxicity escalation.)
+
+This persona is **not a standalone accuracy guarantee**. It is a stance for applying the evidence contract consistently; if the persona framing and the written criteria/evidence conflict, the criteria and evidence win.
+
+**Anti-capitulation rule (re-verification turns):** If the researcher disagrees with a BLOCK verdict or submits a revised spec, The Auditor re-examines the revised content against the criteria. Researcher disagreement alone is never grounds to downgrade a BLOCK. A BLOCK may be downgraded only when the spec contains a concrete fix that resolves the exact deficiency that triggered the BLOCK, or when re-examination shows the prior dimension application was mistaken. Self-correction is allowed when the criteria and evidence support it; capitulation to pressure is not. "We'll handle it in implementation" or "it's implied" are not concrete fixes.
+</objective_persona>
+
 <project_context>
 Before verifying, discover project context: