bizlp dev-spec Lint Rule Reference (ADR-0062 / 5 check + Verdict + Walking Skeleton 辞書 SSoT)

Status: SSoT (ADR-0062 で確立、2026-05-25) 対象: docs/dev/dev_*.md (起案中、現状 0 files) の起案者・レビュアー・AI Agent (Claude / Gemini / GPT) / docs/implementation/legacy-dev/ (162 files、scope 外) 検証: scripts/B6_consistency_check.js (ADR-0029 起源、ロジック本体) + scripts/adr-lint-doc-consistency.mjs (本 doc ↔ code ↔ B6 コメントの 3 way 整合、Phase 2 で実装予定) 根拠 ADR:

• ADR-0062 — dev-spec-lint Rule Reference SSoT 確立
• ADR-0058 — frontmatter-lint パターン (同パターン第二適用)
• ADR-0054 — 10 節構造の確立
• ADR-0029 — B6 ロジック起源

1. Purpose & Scope

本 doc は scripts/B6_consistency_check.js:50-220 に実装された 全 5 dev-spec lint check + 判定基準 (GO / CONDITIONAL GO / NO-GO) + Walking Skeleton 4 要素辞書 + legacy-dev 扱い の規約を 1 箇所に集約した Single Source of Truth (SSoT) である。ADR-0029 本文 / B6 ソースコメント / ADR-0028 (Walking Skeleton) に分散していた根拠を、Discovery (Summary Table) + Detail (各 check 深掘り) + 判定基準 + Walking Skeleton 参照の四層構造で集約する。

対象読者:

• dev_spec 起案者: docs/dev/dev_*.md に新規 spec を追加する前に §4 Summary Table と §6 Verdict Rules / §7 Walking Skeleton を読む
• PR レビュアー: CI で dev-spec-* check が fail した時の rule 解釈根拠として参照
• AI Agent: dev spec 起案・レビュー時の品質ガードレール根拠
• Jr 入社時 (2026-10): onboarding 主要参照先 (CLAUDE.md / git_workflow.md / frontmatter-lint_rules.md と並ぶ品質規約 SSoT)

Non-Goals: B6_consistency_check.js 本体の autofix 実装 / 過去 ADR-0029 / ADR-0062 本文の書き換え (本 doc から過去 ADR への片方向参照リンクのみ、Immutability 遵守)。

2. Severity Legend

5 check のうち critical 2 件 (slice / nav) / minor 3 件 (references / walking-skeleton / constraints)。critical は仕様書がそもそも開発パイプラインに乗らないリスク、minor は将来の保守性・追跡性のリスク。

3. Category Legend

4. Summary Table (Discovery Layer)

集計: critical 2 件 / minor 3 件 / 対象 docs/dev/dev_*.md (現 0 件、Jr 入社後 2026-10 以降で増分)。docs/implementation/legacy-dev/ (162 files) は §8 で明示的に scope 外。

5. Validation Rules (Detail)

5.1 dev-spec-adr-references

id: dev-spec-adr-references
severity: minor  # 各 ADR ごとに 1 件
category: references
since: 2026-05-25  # ADR-0062 採択日
status: active
fixable: false
description: ADR-0010 / 0019 / 0020 / 0021 の 4 件を参照
related_adrs: [ADR-0010, ADR-0019, ADR-0020, ADR-0021, ADR-0029, ADR-0062]

Rationale

dev spec は UC スライスのモジュラーモノリス番台 (ADR-0010) と LangGraph パイプライン (ADR-0019) と UC スライス開発パラダイム (ADR-0020) と Walking Skeleton 構造 (ADR-0021) を前提とする。これら 4 ADR への明示参照がないと、新規起案者・Jr エンジニア・AI Agent が「なぜこの番台に置くのか」「なぜこの粒度なのか」を遡れず、改修時に整合性ある判断ができない。各 ADR について 1 件ずつ minor として記録する (max 4 minor)。

❌ FAIL Example

# UC-3-S01 仕様書

## 概要
...

## 設計根拠
（ADR への言及なし）

✅ PASS Example

# UC-3-S01 仕様書

## 設計根拠・参照 ADR

- ADR-0010 (番台ルール): 400_domain 配下に配置
- ADR-0019 (Pipeline): Gate 3 で本機能を呼び出し
- ADR-0020 (UC スライス): SLA 内 1 スライスとして独立
- ADR-0021 (Walking Skeleton): §7 で 4 要素を網羅

References

• scripts/B6_consistency_check.js:66: REQUIRED_ADRS = ['ADR-0010', 'ADR-0019', 'ADR-0020', 'ADR-0021']
• scripts/B6_consistency_check.js:68-81: 実装本体
• ADR-0029 §B6 check 設計: 4 ADR 必須参照の根拠

5.2 dev-spec-slice-id

id: dev-spec-slice-id
severity: critical
category: slice
since: 2026-05-25
status: active
fixable: false
description: UC-{N}-S{NN} 形式の slice_id 存在 + usecase_dev_mapping.md 整合
related_adrs: [ADR-0020, ADR-0021, ADR-0062]

Rationale

dev spec は UC スライス開発パラダイム (ADR-0020) の粒度単位 (UC-{N}-S{NN}) で起案される。slice_id がない / usecase_dev_mapping.md の該当行と不整合な場合、Backlog 同期 (ADR-0030) と Gate 0-4 Pipeline が機能せず、後段の B5 / B6 / B7 / B8 すべてが破綻する。critical 扱いとし merge ブロック相当とする。

❌ FAIL Example (slice_id 未記載)

# 月次決算自動化

## 概要
| 項目 | 内容 |
|------|------|
| 起案者 | 代表取締役 |
| 起案日 | 2026-05-25 |
（slice_id 行なし）

❌ FAIL Example (mapping 不整合)

# UC-3-S99 仕様書

（usecase_dev_mapping.md に UC-3-S99 のエントリなし）

✅ PASS Example

# UC-3-S01 月次仕訳エクスポート

## 概要

| 項目 | 内容 |
|------|------|
| slice_id | UC-3-S01 |
| 番台 | 400_domain |
| ADR | ADR-0010 / 0019 / 0020 / 0021 |

（`docs/_internal/02_project/usecase_dev_mapping.md` に UC-3-S01 行が存在）

References

• scripts/B6_consistency_check.js:87: regex /UC-(\d+)-S(\d{2})/
• scripts/B6_consistency_check.js:88-117: 実装本体 (mapping 整合チェックを含む)
• docs/_internal/02_project/usecase_dev_mapping.md: slice_id ↔ dev spec の対応表 SSoT
• ADR-0020 §UC スライス粒度定義

5.3 dev-spec-nav-registration

id: dev-spec-nav-registration
severity: critical
category: nav
since: 2026-05-25
status: active
fixable: false
description: docs/_config.json nav 配列への登録
related_adrs: [ADR-0029, ADR-0055, ADR-0062]

Rationale

docs/_config.json nav 配列に登録されていない dev spec は静的サイト build で公開されず、Jr エンジニア / 将来 stakeholder からは「存在しない仕様」と同等になる。ADR-0055 (<NS>.<group>.<page_index> nav 形式) への登録は merge 必須要件で、未登録の merge は実質的なドキュメント Loss となる。critical 扱い。

❌ FAIL Example

# docs/dev/dev_uc-3-s01_monthly-export.md は存在するが
$ grep "dev_uc-3-s01_monthly-export" docs/_config.json
# (no output — nav 未登録)

✅ PASS Example

// docs/_config.json
{
  "nav": [
    ...
    {
      "group": "dev.03_uc-slice",
      "pages": [
        {
          "file": "dev/dev_uc-3-s01_monthly-export.md",
          "title": "D.03.1 UC-3-S01 月次仕訳エクスポート"
        }
      ]
    }
  ]
}

References

• scripts/B6_consistency_check.js:123-139: 実装本体
• ADR-0055 (nav 命名規約): <NS>.<group>.<page_index> 形式必須
• docs/_internal/05_how-to/nav-lint-guide.md (ADR-0051): nav 整合性 lint

5.4 dev-spec-walking-skeleton

id: dev-spec-walking-skeleton
severity: minor  # 各要素ごとに 1 件 (max 4 minor)
category: walking-skeleton
since: 2026-05-25
status: active
fixable: false
description: Walking Skeleton 4 要素 (認証 / DDL / 監査ログ / Feature Flag) への言及
related_adrs: [ADR-0021, ADR-0028, ADR-0062]

Rationale

Walking Skeleton 4 要素 (ADR-0028 §Walking Skeleton の位置づけ line 73 SSoT) は、UC スライスが監査・コンプライアンス要件を満たすための横断的先行実装制約。後から追加すると移行コストが指数的に増大するため、初回実装から横串で貫通させる必要がある。各 dev spec が 4 要素すべてに対し「実装方針」または「不要 (理由)」を明記する必要がある。

各要素未言及で 1 件ずつ minor として記録する (max 4 minor)。判定キーワードは §7 Walking Skeleton 4 要素辞書参照。

❌ FAIL Example

# UC-3-S01 仕様書

## 実装方針

Repository pattern で 11_mst_account に書き込み...

（認証 / DDL / 監査ログ / Feature Flag いずれも未言及）

✅ PASS Example

# UC-3-S01 仕様書

## Walking Skeleton 4 要素

| 要素 | 本スライスでの扱い |
|---|---|
| 認証 | OAuth (clasp 経由)、ScriptApp.getOAuthToken() を Env 経由で取得 |
| DDL | setupAllSchemas() で 33_wrk_export に列追加 |
| 監査ログ | 98_audit_log に export 完了 row を logAudit() で書込 |
| Feature Flag | PropertiesService.FF_UC3_S01 で段階開放 |

References

• scripts/B6_consistency_check.js:145-164: 実装本体 (4 要素辞書込み)
• ADR-0028 §line 73: Walking Skeleton 4 要素の SSoT 定義
• §7 Walking Skeleton 4 要素辞書 (本 doc): 判定キーワード一覧

5.5 dev-spec-gas-six-min

id: dev-spec-gas-six-min
severity: minor
category: constraints
since: 2026-05-25
status: active
fixable: false
description: GAS 6 分制限 (360 秒) への言及
related_adrs: [ADR-0029, ADR-0062]

Rationale

Google Apps Script は 1 関数の実行時間 6 分 (360 秒) 上限という GAS 固有制約 (CLAUDE.md §GAS 固有制約) を持つ。長尺処理を含む dev spec が 6 分制限への対処 (chunk 化 / Time-driven Trigger / Properties 進捗保存) を明記していないと、本番で timeout 失敗→部分 commit 状態となり監査リスクが生じる。エッジケース or 実装上の注意点に言及があれば pass。

❌ FAIL Example

# UC-5-S03 全件 csv 取込

## 実装方針

UrlFetchApp.fetchAll() で全件 fetch → 一括 SpreadsheetApp.appendRow() で書込み

（6 分 / 360 秒への言及なし）

✅ PASS Example

# UC-5-S03 全件 csv 取込

## 実装方針

UrlFetchApp.fetchAll() で全件 fetch → chunk 化して書込み。

## エッジケース

- **GAS 6 分制限**: 1 万行超は 360 秒で打切られるため、500 行 chunk + PropertiesService 進捗保存 + Time-driven Trigger で再開

References

• scripts/B6_consistency_check.js:170-180: 実装本体 (6 分 / 6分 / 360秒 / 360 秒 のいずれかでマッチ)
• CLAUDE.md §GAS 固有制約: 6 分上限の根拠
• ADR-0029 §B6 設計: minor 扱いの根拠 (致命ではないが運用罠の典型)

6. Verdict Rules (GO / CONDITIONAL GO / NO-GO)

scripts/B6_consistency_check.js:185-195 の判定ロジック:

Verdict 判定フロー

flowchart TD
    A[B6 lint 実行] --> B{critical 件数}
    B -->|>= 1| C[NO-GO: merge block]
    B -->|0| D{minor 件数}
    D -->|>= 1| E[CONDITIONAL GO: 起案者裁定]
    D -->|0| F[GO: 完全 pass]
    E --> G[PR description で容認理由記載]
    F --> H[merge 可]
    G --> H

CONDITIONAL GO の運用方針: minor は「将来改修候補」として PR description に「Walking Skeleton: 監査ログ — 本スライスは read-only のため不要」のような容認理由 1 行を必須化する。判断ブレ防止のため、4 ヶ月後の Review After (2026-09-22) で CONDITIONAL GO 発生件数を計測し、上位 minor は critical 昇格 or rule 削除を再評価する。

7. Walking Skeleton 4 要素辞書 (→ ADR-0028)

SSoT 参照: ADR-0028 §Walking Skeleton の位置づけ (line 73) — Walking Skeleton 4 要素の正式定義は ADR-0028 にあり、本 doc から片方向参照。

4 要素の判定キーワード

scripts/B6_consistency_check.js:145-150 の WS_ELEMENTS 配列:

「不要 (理由)」運用

各要素について「本スライスでは不要」と判断する場合、不要 (理由: ...) の形で明記する。判定キーワードにマッチしないと minor 1 件発火するため、不要なら判定キーワードを含む形での明記が必要 (例: 「監査ログ: 不要 (read-only スライスのため logAudit 呼出なし)」)。

8. legacy-dev 162 files の扱い

docs/implementation/legacy-dev/ 配下 162 files は本 lint rule の scope 外 (ADR-0045 §_internal 組織化に基づく過去資産アーカイブ)。理由:

1. Immutable 過去資産: legacy-dev は ADR-0028 / 0029 確立以前の旧構造で起案されており、5 check 全件を retrofit すると ~162 × 30min = ~81h の遡及修正が必要となる
2. 過去 spec を変えない運用: 過去 spec は仕様凍結 + 新規移植時のみ touched する方針 (ADR-0045 §legacy 扱い)
3. CI 除外: scripts/B6_consistency_check.js 自体は docs/dev/dev_*.md のみを対象とし、legacy-dev/ には適用されない

legacy-dev → dev/ への移行手順

legacy-dev のいずれかを新仕様として再起案する場合:

1. docs/dev/dev_uc-N-sNN_<topic>.md として新規ファイル作成
2. legacy-dev からは内容を 手動移植 (機械 copy 禁止、必要部分のみ抽出)
3. B6 lint 全 check を pass させる
4. legacy-dev 側ファイルは凍結 (削除せず、status: superseded frontmatter で後継 spec を related: 指定)
5. usecase_dev_mapping.md に新規 slice_id 行を追加

9. Legacy / Deprecated

該当 rule なし。本 doc 起案時点 (2026-05-25) で全 5 check が status: active。Deprecated 化された check が出た場合は本節に「deprecated 日付」「代替 rule への移行手順」「最終削除予定日」を記載する。

既知の 3 way 整合 follow-up (Phase 2 実装予定)

ADR-0058 で確立した 3 way 整合 CI (scripts/adr-lint-doc-consistency.mjs) の 第三適用例として、本 doc も Phase 2 で:

• scripts/B6_consistency_check.js の REQUIRED_ADRS / WS_ELEMENTS / 6 分 keyword リスト
• 本 doc §4 Summary Table / §5 Rule Details / §7 Walking Skeleton 辞書
• .adr-lint-doc-consistency-allowlist.json の dev_spec_special_cases (初期 ≤ 3 件)

の 3 way 整合を CI で機械強制する。Phase 2 実装は main workspace 側で scripts/adr-lint-doc-consistency.mjs 拡張として進められる予定 (TODO_future.md §7 DOC-OPS に転記)。

10. Changelog