specdo 1.0.2

package/dist/core/skill-content/cross-domain.js

@@ -0,0 +1,291 @@
+/**
+ * Cross-Domain Collaboration Notes
+ *
+ * 每个 domain skill 都会被注入这些"跨领域协同"片段，作为 references/CROSS_DOMAIN.md
+ * 写入 progressive-disclosure 子目录。
+ *
+ * 内容是手写的，因为跨领域协作语义无法从 DomainModule 数据机械推导。
+ * 目的是让 agent 知道：触发了 domain X 时，是否应同时考虑 domain Y、
+ * 在边界处由谁拥有最终决定权、典型冲突点。
+ */
+export const CROSS_DOMAIN_NOTES = {
+    security: `# security — Cross-domain collaboration
+
+The security domain rarely fires alone. It overlays other domains and
+expresses non-functional constraints; treat its checklist as **veto power**
+on the others when the two disagree.
+
+## With architecture
+
+- Auth boundaries / trust zones are architectural concerns; security defines
+  what each zone may carry. Disagreement: security wins on data-classification
+  and least-privilege; architecture wins on transport / topology.
+- Threat-model the integration surface BEFORE picking patterns — a clean
+  hexagonal split is worthless if a port leaks PII.
+
+## With backend
+
+- Every query authored under "backend" must pass security's parameterized-
+  query and authorization checks. Backend owns query shape, security owns
+  injection / IDOR / row-level access.
+- Secret rotation lives here, not in backend operational scripts.
+
+## With frontend
+
+- Output encoding (XSS) is a frontend implementation choice but a security
+  requirement. Frontend chooses the templating library; security audits the
+  escape contract.
+- CSRF tokens / SameSite cookies span both domains — frontend renders, but
+  the policy is security's call.
+
+## With operations
+
+- TLS termination, secret stores, WAF rules, dependency scanning in CI —
+  operations owns the plumbing, security owns the policy.
+- Incident response runbooks need both inputs.
+
+## With quality
+
+- Test coverage for auth flows (positive, negative, privilege escalation) is
+  a quality concern; the *list of attacks to cover* is security's deliverable.
+
+## Conflict triage
+
+If two checklists collide, security wins for: data classification, key
+material, audit-trail completeness, deny-by-default. The other domain wins
+for: structural choice (service shape, data model, render strategy).
+`,
+    architecture: `# architecture — Cross-domain collaboration
+
+Architecture sets the structural skeleton everyone else lives in. It rarely
+adds *correctness* clauses on its own; it constrains how the others compose.
+
+## With backend
+
+- Service boundaries, port/adapter shapes, transactional scope: architecture
+  proposes, backend implements. Backend may push back if the proposal forces
+  N+1 queries or distributed transactions.
+- Data ownership per service is architecture's call.
+
+## With frontend
+
+- Frontend/backend contract (REST, GraphQL, RPC, events) is architectural;
+  frontend then chooses client library + state shape.
+- BFF (backend-for-frontend) decisions are joint, owned by architecture
+  but vetted by frontend for ergonomics.
+
+## With security
+
+- See security/CROSS_DOMAIN: architecture defines zones, security defines
+  what may cross them. Whenever a proposed boundary moves PII / secrets,
+  re-open the threat model.
+
+## With operations
+
+- Deployable unit shape (monolith, services, functions) is the
+  architecture↔operations contract. Architecture decides "what's a unit",
+  operations decides "how it ships and runs".
+- Architectural change ⇒ runbook change. Tag operations on every
+  topology-affecting proposal.
+
+## With quality
+
+- Testability is non-negotiable architecture pressure: any boundary that
+  resists unit testing is an anti-pattern even if it "feels clean".
+- Cross-service contract tests are an architecture deliverable.
+
+## Conflict triage
+
+Architecture loses to security on data-flow restrictions; loses to
+operations on deploy-feasibility; loses to backend on real-world data-shape
+performance. It wins on: long-term modular evolution, boundary clarity,
+public-API stability.
+`,
+    operations: `# operations — Cross-domain collaboration
+
+Operations owns *how the system runs in production*. Most other domains
+generate operations requirements as side-effects of their own deliverables.
+
+## With architecture
+
+- See architecture/CROSS_DOMAIN: deployable unit shape is the contract.
+  Operations rejects topologies it cannot observe or roll back.
+- Migration / canary / blue-green strategy is operations' call once
+  architecture has settled the unit shape.
+
+## With backend
+
+- Database migrations, queue / cache provisioning, connection-pool sizing:
+  joint, but operations owns the runbook and the alarm thresholds.
+- Backward-compatibility windows during deploys are operations' veto.
+
+## With frontend
+
+- Static asset CDN, cache headers, build artifact versioning, error-tracking
+  integration are operations concerns; frontend owns the build pipeline shape.
+- Feature-flag system: operations supplies the platform, frontend uses it.
+
+## With security
+
+- See security/CROSS_DOMAIN: operations runs the plumbing for security
+  policy. Secret stores, TLS certificates, audit-log retention all live here.
+- Incident response on-call rotations and access reviews are operations.
+
+## With quality
+
+- CI/CD pipeline, flaky-test quarantine, performance regression gates are
+  operations' tooling for quality's policies.
+
+## Conflict triage
+
+Operations vetoes anything it cannot monitor, roll back, or scale. Wins
+on: release safety, observability, capacity planning. Loses to security on
+audit/retention policy; loses to architecture on long-term unit shape.
+`,
+    backend: `# backend — Cross-domain collaboration
+
+Backend owns data + business-logic execution. It produces evidence the
+other domains audit.
+
+## With architecture
+
+- Architecture proposes the service / boundary; backend implements with
+  concrete data shapes and persistence choices. Backend pushes back on
+  proposals that hide N+1, fan-out joins, or distributed-transaction needs.
+
+## With frontend
+
+- API contract (shape, pagination, error envelope) is a joint deliverable.
+  Backend owns canonical types; frontend owns DTOs / view models.
+- Optimistic-update friendliness is a backend concern (idempotency keys,
+  ETag support, status codes).
+
+## With security
+
+- See security/CROSS_DOMAIN: every backend query passes security's audit
+  for parameterization, IDOR prevention, and authorization checks.
+- Soft-delete vs hard-delete is security ↔ backend joint (compliance +
+  storage cost).
+
+## With operations
+
+- Migration scripts, index changes, connection-pool tuning: backend writes,
+  operations runs and monitors. Joint runbook required.
+- Backward-compatibility windows during schema migrations are operations'
+  ask but backend's design constraint (additive-then-removal pattern).
+
+## With quality
+
+- Test pyramid: unit tests for pure business logic, integration tests for
+  data access, contract tests for the public API. Backend owns the structure;
+  quality owns the discipline.
+
+## Conflict triage
+
+Backend wins on: data model fidelity, transactional correctness, read/write
+performance. Loses to security on injection/authorization, loses to
+operations on migration safety, loses to architecture on long-term API
+stability when the two collide.
+`,
+    quality: `# quality — Cross-domain collaboration
+
+Quality is a *meta-domain*: it overlays whatever business-domain skills are
+matched, enforcing TDD discipline, review rigor, and regression prevention.
+
+## With every domain
+
+- Quality has no exclusive checklist of its own; instead, every business-
+  domain's verify.checklist must be **enforceable by automation** under
+  quality's discipline. If a check requires manual eyeballing only, quality
+  flags it as a refactor candidate.
+
+## With security
+
+- Test coverage for auth / authz / injection paths is jointly owned: the
+  attacks to cover are security's, the test infrastructure is quality's.
+- Security audit findings flow into quality's regression-test backlog.
+
+## With backend
+
+- Contract tests (provider + consumer) sit on quality's pyramid but the
+  contracts themselves are backend deliverables. Flaky contract tests are
+  quality's escalation, backend's fix.
+
+## With frontend
+
+- Visual regression / a11y testing infrastructure is quality; the snapshot /
+  axe rule set is frontend.
+- Component testing strategy (RTL + jsdom vs full browser) is a joint
+  decision.
+
+## With architecture
+
+- Testability is the joint pressure: any architectural boundary that
+  resists testing must be revisited. Architecture loses ties here.
+
+## With operations
+
+- CI / CD configuration, flaky-test quarantine, mutation testing, mutation-
+  coverage gates: quality writes the policy, operations runs the pipeline.
+- Performance regression gates are joint.
+
+## Conflict triage
+
+Quality never wins a design argument on its own ("we should restructure
+this for testability") — it wins by tagging in the relevant business domain
+(usually architecture) to make the case structurally. Its veto is on:
+PR merge without proportionate test evidence, broken regression suite,
+test coverage regression on critical paths.
+`,
+    frontend: `# frontend — Cross-domain collaboration
+
+Frontend owns the user-facing surface — rendering, interaction, perceived
+performance. It consumes contracts from backend and is policed by security
+on output handling.
+
+## With backend
+
+- API contract (REST / GraphQL / RPC shape, error envelope, pagination,
+  status-code semantics) is joint. Frontend asks for ergonomic shapes;
+  backend asks for performance-friendly shapes.
+- Optimistic UI requires backend support (idempotency keys, ETag, retry-
+  safe POSTs). Not all flows can be optimistic — frontend must defer to
+  backend's safe-set.
+
+## With security
+
+- See security/CROSS_DOMAIN: every render of user-controlled content runs
+  through security's encoding rules. Frontend chooses the templating
+  library; security audits the escape contract.
+- CSRF / CSP / SameSite cookies are policy → security, mechanism → frontend.
+
+## With architecture
+
+- Routing topology (SPA, MPA, RSC, islands) is architectural; component
+  shape (atomic, feature-folder) is frontend. The boundary is "where the
+  network actually splits".
+- BFF (backend-for-frontend) decisions are joint, vetted by frontend for
+  ergonomics.
+
+## With operations
+
+- Build pipeline (Vite / Next / Webpack), CDN caching, source-map upload,
+  error-tracking integration: frontend owns the build, operations owns the
+  delivery infrastructure.
+- Feature flags: operations provides the platform; frontend consumes.
+
+## With quality
+
+- a11y testing, visual regression, RTL component testing, lighthouse
+  budgets: infrastructure is quality, rule set is frontend.
+- "Test from the user's perspective" maxim is jointly owned.
+
+## Conflict triage
+
+Frontend wins on: user-perceived performance, a11y compliance, interaction
+ergonomics. Loses to backend on API shape when the two collide (the
+contract is the source of truth — DTO mapping is the price). Loses to
+security on output encoding. Loses to operations on bundle size budgets.
+`,
+};
+//# sourceMappingURL=cross-domain.js.map

package/dist/core/skill-content/cross-domain.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"cross-domain.js","sourceRoot":"","sources":["../../../src/core/skill-content/cross-domain.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,MAAM,CAAC,MAAM,kBAAkB,GAA2B;IACxD,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6CX;IAEC,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6Cf;IAEC,UAAU,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwCb;IAEC,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4CV;IAEC,OAAO,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiDV;IAEC,QAAQ,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAiDX;CACA,CAAC"}

package/dist/core/skill-content/protocol-examples.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Protocol Skill Examples
+ *
+ * 手写的 do/don't 代码示例，给 protocol skill 的 references/EXAMPLES.md。
+ * 目前只有 review-to-solid 一个 protocol，所以这里只有一段内容。
+ *
+ * 内容覆盖：S / O / L / I / D 各一段，每段含
+ *   - 抽象违例 → 修复方向（不是手把手改写）
+ *   - review-to-solid 工作流如何识别它
+ *   - 与"轻度 review"(P3) vs "重构必需"(P1) 的分级
+ */
+export declare const PROTOCOL_EXAMPLES: Record<string, string>;
+//# sourceMappingURL=protocol-examples.d.ts.map

package/dist/core/skill-content/protocol-examples.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"protocol-examples.d.ts","sourceRoot":"","sources":["../../../src/core/skill-content/protocol-examples.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,eAAO,MAAM,iBAAiB,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAiLpD,CAAC"}

package/dist/core/skill-content/protocol-examples.js

@@ -0,0 +1,190 @@
+/**
+ * Protocol Skill Examples
+ *
+ * 手写的 do/don't 代码示例，给 protocol skill 的 references/EXAMPLES.md。
+ * 目前只有 review-to-solid 一个 protocol，所以这里只有一段内容。
+ *
+ * 内容覆盖：S / O / L / I / D 各一段，每段含
+ *   - 抽象违例 → 修复方向（不是手把手改写）
+ *   - review-to-solid 工作流如何识别它
+ *   - 与"轻度 review"(P3) vs "重构必需"(P1) 的分级
+ */
+export const PROTOCOL_EXAMPLES = {
+    'review-to-solid': `# review-to-solid — Do / Don't examples
+
+Pairs of "violation" / "fix direction" across the five SOLID letters,
+annotated with the severity the protocol would tag (P1/P2/P3) and the
+workflow step that surfaces it.
+
+---
+
+## S — Single Responsibility
+
+**Violation (P2, flagged in Step 3 "Solid lens"):**
+
+\`\`\`ts
+class UserService {
+  async createUser(input: UserInput): Promise<User> {
+    const validated = this.validate(input);              // validation
+    const hashed = await bcrypt.hash(input.password, 12); // crypto
+    const user = await this.db.insert('users', validated);// persistence
+    await this.mailer.send(user.email, 'welcome');        // I/O
+    await this.metrics.increment('user.created');         // telemetry
+    return user;
+  }
+}
+\`\`\`
+
+Five reasons to change in one method. Reviewer should write in the
+**Findings** section:
+
+> **[P2 / S]** \`UserService.createUser\` couples validation, crypto,
+> persistence, transactional email, and telemetry. Extract three:
+> \`PasswordHasher\`, \`UserMailer\` (post-commit hook), and metrics
+> middleware. Validation can stay if it's pure input shape.
+
+**Fix direction:**
+
+\`\`\`ts
+class UserService {
+  constructor(
+    private hasher: PasswordHasher,
+    private mailer: UserMailer,
+    private db: DB,
+  ) {}
+  async createUser(input: UserInput): Promise<User> {
+    const validated = this.validate(input);
+    const passwordHash = await this.hasher.hash(input.password);
+    const user = await this.db.insert('users', { ...validated, passwordHash });
+    this.mailer.sendWelcomeAfterCommit(user);
+    return user;
+  }
+}
+\`\`\`
+
+(Metrics moved to a middleware decorator; not shown.)
+
+---
+
+## O — Open / Closed
+
+**Violation (P2, flagged in Step 3):**
+
+\`\`\`ts
+function priceFor(item: Item, tier: 'free' | 'pro' | 'enterprise'): number {
+  if (tier === 'free') return item.basePrice;
+  if (tier === 'pro') return item.basePrice * 0.9;
+  if (tier === 'enterprise') return item.basePrice * 0.7;
+  throw new Error('unknown tier');
+}
+\`\`\`
+
+Every new tier forces a code edit + redeploy. **Fix direction:** push the
+discount into a \`PricingStrategy\` data table or per-tier object so adding
+a tier means adding data, not changing behavior code.
+
+> **[P2 / O]** \`priceFor\` is closed only to data; open to behavior. Add
+> a tier registry that drives discount lookup; the conditional ladder goes
+> away.
+
+---
+
+## L — Liskov Substitution
+
+**Violation (P1, flagged in Step 3 — substitution failures are correctness
+bugs, not stylistic):**
+
+\`\`\`ts
+class Rectangle {
+  setWidth(w: number) { this.w = w; }
+  setHeight(h: number) { this.h = h; }
+  area() { return this.w * this.h; }
+}
+class Square extends Rectangle {
+  setWidth(w: number) { this.w = w; this.h = w; }
+  setHeight(h: number) { this.w = h; this.h = h; }
+}
+// callers expecting Rectangle break when they get Square
+\`\`\`
+
+> **[P1 / L]** \`Square extends Rectangle\` violates LSP: setters mutate
+> the sibling axis, so any caller using \`.setWidth(x); .setHeight(y);
+> .area()\` returns x*y for a Rectangle but y² for a Square. Either drop
+> the inheritance (composition: Shape interface) or make both immutable
+> (no setters).
+
+---
+
+## I — Interface Segregation
+
+**Violation (P3, flagged in Step 3 — cosmetic unless it breaks evolution):**
+
+\`\`\`ts
+interface Worker {
+  work(): void;
+  eat(): void;     // robots don't eat
+  sleep(): void;   // robots don't sleep
+}
+\`\`\`
+
+> **[P3 / I]** \`Worker\` mixes orthogonal concerns. Split into
+> \`Workable\`, \`Feedable\`, \`Restable\`; let each implementor pick.
+> Low urgency if no second implementor exists yet — note it for the next
+> evolution, don't block this PR.
+
+---
+
+## D — Dependency Inversion
+
+**Violation (P1 when the dependency is I/O, P3 when it's a value type):**
+
+\`\`\`ts
+class OrderService {
+  private mailer = new SmtpMailer({ host: 'smtp.gmail.com' }); // hardcoded
+  async place(order: Order) {
+    await this.mailer.send(order.customerEmail, 'order placed');
+  }
+}
+\`\`\`
+
+Cannot unit-test without a real SMTP server.
+
+> **[P1 / D]** \`OrderService\` constructs \`SmtpMailer\` internally,
+> blocking unit-testability and forcing a config bleed. Inject a
+> \`Mailer\` interface; let the composition root pick \`SmtpMailer\` vs
+> \`FakeMailer\` (tests) vs \`NoopMailer\` (CI).
+
+**Fix direction:**
+
+\`\`\`ts
+interface Mailer { send(to: string, msg: string): Promise<void>; }
+class OrderService {
+  constructor(private mailer: Mailer) {}
+  async place(order: Order) {
+    await this.mailer.send(order.customerEmail, 'order placed');
+  }
+}
+\`\`\`
+
+---
+
+## Workflow reminders
+
+- **Step 3** ("Solid lens") is the only step where these patterns are
+  surfaced. Don't sneak SOLID critique into Step 1/2 (which is reading +
+  smell-listing).
+- **Severity assignment** must be consistent across the same PR — pick a
+  rubric (e.g. "P1 = correctness or test-blocker; P2 = scaling pain; P3 =
+  cosmetic"), state it once in the **Final Verdict** preamble, then apply.
+- **Step 6** (Re-review) loops back to Step 4 if the fix introduces new
+  violations. The Delta Table records initial vs final counts per letter.
+
+## Anti-pattern: SOLID-style review on a 5-line bug fix
+
+Triggering review-to-solid on \`if (x === null) return\` is over-eager.
+The protocol's \`suppressionPhrases\` and \`doNotUseWhen\` exist precisely
+for this — see the SKILL.md header. When in doubt, do a light review
+(comment quality, test coverage, naming) and skip the full SOLID pass.
+`,
+};
+//# sourceMappingURL=protocol-examples.js.map

package/dist/core/skill-content/protocol-examples.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"protocol-examples.js","sourceRoot":"","sources":["../../../src/core/skill-content/protocol-examples.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,MAAM,CAAC,MAAM,iBAAiB,GAA2B;IACvD,iBAAiB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA+KpB;CACA,CAAC"}

package/dist/core/skill-content/workflow-content.d.ts

@@ -0,0 +1,25 @@
+/**
+ * Workflow Skill Content
+ *
+ * 5 个工作流 skill 的完整 progressive-disclosure 内容：
+ *   每个 skill 由 1 个精炼 SKILL.md（≤ 50 行）+ 1-2 个 references/*.md 组成。
+ *
+ *   - SKILL.md: When to use / Quick command / 链接 references / Next step
+ *   - references/REFERENCE.md: 完整命令矩阵、所有标志、exit code、错误恢复
+ *   - references/EXAMPLES.md: 1-2 段真实对话样本
+ *
+ * 当前内容约束：
+ *   - 不导出 `specdo-init` skill（input 由 agent 直接引导）
+ *   - exit code 列表对齐当前 CLI 行为
+ *   - description 包含真实 trigger 短语（"let's plan", "scaffold the change" 等）
+ *
+ * Source of truth 为代码本身（运行时渲染，无模板文件）。
+ */
+export interface WorkflowSkillContent {
+    name: string;
+    description: string;
+    body: string;
+    references: Record<string, string>;
+}
+export declare const WORKFLOW_SKILLS: WorkflowSkillContent[];
+//# sourceMappingURL=workflow-content.d.ts.map

package/dist/core/skill-content/workflow-content.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"workflow-content.d.ts","sourceRoot":"","sources":["../../../src/core/skill-content/workflow-content.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH,MAAM,WAAW,oBAAoB;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;IACpB,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;CACpC;AA0/CD,eAAO,MAAM,eAAe,EAAE,oBAAoB,EAmDjD,CAAC"}