kotonoha 0.3.0 → 0.4.1

package/CHANGELOG.md

@@ -7,6 +7,43 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.4.1] - 2026-10-19
+
+### Added
+
+- Add an Obsidian knowledge-note template and doctype guide with core
+  Templates variables, YAML properties, wikilinks, a callout, and tasks.
+- Add an independent `obsidian-vault` skill for scoped convention discovery, note
+  creation, related-note suggestions, link diagnosis and approval-gated
+  Japanese proofreading saves on Linux local files.
+- Add a locked offline launcher, content-bound plans and success receipts,
+  protected Obsidian syntax, and an independent 100-note acceptance fixture.
+
+### Changed
+
+- Rename the development Skill from `obsidian` to `obsidian-vault`, including
+  its installation name and `test:obsidian-vault` runner. Historical approval
+  records retain their original paths; the execution contract is relocated
+  without changing its approved bytes.
+
+## [0.4.0] - 2026-10-19
+
+### Added
+
+- Add duplicate-particle/word, Japanese bracket, and paragraph style-mixing
+  diagnostics, plus a minimal-edit `proofread` skill mode.
+- Add a Markdown-aware invariant gate with protected-content checks and
+  required hash-bound semantic review of edits.
+
+### Fixed
+
+- Avoid treating obligation expressions as double-negative errors and
+  conclusion questions as formulaic assertions.
+- Keep shorter fence markers and fence-like info strings inside code blocks
+  out of prose diagnostics.
+- Require the invariant gate and current semantic review to pass before
+  claiming Japanese prose optimization completed.
+
 ## [0.3.0] - 2026-09-30
 
 ### Added

package/README-ja.md

@@ -53,10 +53,29 @@ kotonohaは文書構造と技術的な不変条件を固定してから日本語
 | 証拠に基づく解説・提言 | 技術・事業White Paper | `white-paper` |
 | 情報提供依頼 | RFI | `rfi` |
 | 提案依頼 | RFP | `rfp` |
+| ナレッジノート | Obsidianのノート、再利用可能なテンプレート | `obsidian` |
 | 技術記事 | Zenn記事 | `zenn` |
 | 技術記事 | Qiita記事 | `qiita` |
 
-再利用可能なテンプレートには、README、設計判断、ユーザーマニュアル、PR説明があります。要件定義、システム設計、テスト、運用、移行、セキュリティの各文書にも対応しています。技術提案、Blueprint、White Paper、RFI、RFP、Qiita記事のテンプレートも含まれます。すべての文書種別には、`skills/tech-writer/references/doctypes/`配下に専用の構成ガイドとレビューチェックリストがあります。
+再利用可能なテンプレートには、README、設計判断、ユーザーマニュアル、PR説明があります。要件定義、システム設計、テスト、運用、移行、セキュリティの各文書にも対応しています。技術提案、Blueprint、White Paper、RFI、RFP、Obsidianノート、Qiita記事のテンプレートも含まれます。すべての文書種別には、`skills/tech-writer/references/doctypes/`配下に専用の構成ガイドとレビューチェックリストがあります。
+
+Obsidianでは、[`obsidian.md`](skills/tech-writer/assets/templates/obsidian.md)をVault内のテンプレートフォルダーにコピーし、標準のTemplatesプラグインでそのフォルダーを指定します。名前を付けた空のノートで **Templates: Insert template** を実行すると、タイトルと挿入日が展開されます。プロパティ、内部リンク、コールアウト、タスクを含み、コミュニティプラグインは不要です。kotonohaはVaultの設定を変更しません。詳しい設定方法と制約は、[Obsidianガイド](skills/tech-writer/references/doctypes/obsidian.md)を参照してください。
+
+## Obsidian Vaultの操作
+
+専用の`obsidian-vault`は、Vaultの規約確認、ノート新規作成、関連ノート候補、内部リンク診断、日本語添削を担当します。
+文書構成はtech-writer、日本語表現はjapanese-proseを利用するため、3つのSkillを同じ場所へ導入してください。
+初期対応はLinux、CPython 3.12、uvです。Obsidianアプリ、MCP、プラグインには依存しません。
+
+Vault、読み取り範囲、モデルに渡す情報を利用者が明示し、保存する場合は正確な差分と計画を承認します。
+保存は専用CLIのapplyだけで行い、添削時の記法保護とハッシュ付き意味レビューを迂回しません。
+未解決リンクを誤りと断定せず、自動修復もしません。
+処理はオフライン・lock付きで起動します。依存関係の初回準備は別途の許可が必要です。
+依頼例、コマンド、コピーの保持と復旧は[操作ガイド](skills/obsidian-vault/references/workflow.md)を参照してください。
+
+保存は確認できたローカルFSに限定し、シンボリックリンク、維持できない属性、複数ハードリンクを拒否します。
+拡張属性付きファイルも保存非対応であり、SELinuxラベルなどの削除を回避策にしません。
+最終照合直後の外部編集やLLMの誤判断は完全には防げず、ホストを隔離する機能でもありません。
 
 ## consulting-analystの機能
 
@@ -97,7 +116,7 @@ White Paper向けの分析を作成して
 
 - GitHub Copilot CLIがインストールされていること
 - tech-writerの構造lintを実行する場合はPython 3.9以上
-- 同梱`japanese-prose`の文章lint、読解負荷分析、アウトライン抽出、用語検査を実行する場合はPython 3.10以上と`uv`。GiNZA、`ja_ginza`、spaCyは初回実行時に`uv`が解決
+- 同梱`japanese-prose`の文章lint、読解負荷分析、アウトライン抽出、用語検査、編集前後の不変条件検査を実行する場合はPython 3.10以上と`uv`。GiNZA、`ja_ginza`、spaCy、Markdown解析用の依存関係は、各スクリプトの初回実行時に`uv`が解決
 
 ### npmからインストール
 
@@ -110,19 +129,20 @@ npx kotonoha install
 
 ### 同梱スキルをまとめてインストール
 
-`kotonoha install`は、まだ存在しない同梱スキルをすべてインストールします。次のコマンドは、`consulting-analyst`、`tech-writer`、`japanese-prose`、`presentation-planner`を`.github/skills/`へインストールします。
+`kotonoha install`は、まだ存在しない同梱スキルをすべてインストールします。次のコマンドは、`consulting-analyst`、`tech-writer`、`japanese-prose`、`obsidian-vault`、`presentation-planner`を`.github/skills/`へインストールします。
 
 ```bash
 npm install --save-dev kotonoha
 npx kotonoha install --skill all
 ```
 
-`--skill all`が既定値であるため、`npx kotonoha install`も同じ動作です。4つのスキルがインストールされたことを確認します。
+`--skill all`が既定値であるため、`npx kotonoha install`も同じ動作です。5つのスキルがインストールされたことを確認します。
 
 ```bash
 test -f .github/skills/consulting-analyst/SKILL.md
 test -f .github/skills/tech-writer/SKILL.md
 test -f .github/skills/japanese-prose/SKILL.md
+test -f .github/skills/obsidian-vault/SKILL.md
 test -f .github/skills/presentation-planner/SKILL.md
 ```
 
@@ -136,6 +156,10 @@ npx kotonoha install --skill all --force
 
 kotonohaには独自開発の`japanese-prose`が同梱されるため、文章最適化スキルを別途インストールする必要はありません。`npx kotonoha install`により`tech-writer`と同じスキルルートへ配置され、GiNZAを使った文章lint、読解負荷検査、用語抽出、アウトライン検査、反復的な文章レビューをローカルで実行できます。この実装はkotonoha向けにゼロから開発しており、`natural-japanese`のソースコードを含みません。GiNZAの依存関係とライセンス情報は`skills/japanese-prose/NOTICE.md`に記録しています。
 
+文章lintでは、隣接する助詞・単語の重複、和文括弧の不整合、同一段落内の敬体・常体の混在も確認します。指摘は自動置換の指示ではなく、文脈を確認する対象です。`proofread`モードでは、任意の言い換えを避け、誤字と文法上の誤りだけを最小限に修正します。100点満点のスコアは確認箇所を探す補助であり、訂正精度や品質の保証ではありません。
+
+編集前の原文は変更せずに保存します。同梱の`scripts/invariants.py`が、数値、識別子、コード、表、リンク、指定された固有名詞・専門用語などの変更を検査します。編集した文章には、原文と編集後のファイルのハッシュに対応した意味保存レビューが必要です。機械的な一致だけでは、意味が保たれたとは判定しません。レビュー形式と終了コードは、[`review-workflow.md`](skills/japanese-prose/references/review-workflow.md)を参照してください。
+
 自然言語で指示するときは、GiNZAを明示する必要はありません。「日本語文書を自然にする」「読みやすくする」「簡潔にする」「AIらしい定型表現を減らす」といった依頼をすると、同梱の文章最適化ワークフローが呼び出されます。
 
 ```text
@@ -150,6 +174,7 @@ README-ja.mdの日本語を自然で読みやすい表現に修正して
 目的に応じて、次のようにモードを指定できます。
 
 - ファイルを修正する: `README-ja.mdの日本語表現を最適化して`
+- 誤りだけを修正する: `README-ja.mdをproofreadモードで校正して。任意の言い換えはせず、誤字と文法上の誤りだけを最小限に修正して`
 - 修正せずにレビューする: `README-ja.mdの日本語をレビューして。ファイルは修正しないで`
 - 採点だけ行う: `README-ja.mdの日本語表現を100点満点で採点して`
 - すべての診断を実行する: `README-ja.mdをfullモードで日本語表現最適化して`
@@ -157,7 +182,9 @@ README-ja.mdの日本語を自然で読みやすい表現に修正して
 
 新しい日本語文書では、`このリポジトリの日本語READMEを作成して`のように依頼すると、`tech-writer`が下書きと構造レビューを行い、rubber-duck reviewの前にGiNZAベースの文章最適化を実行します。文章最適化を確実に指定する場合は、`<ファイル名>を技術文書として作成または修正し、GiNZAによる日本語表現最適化まで実施して`と指示します。
 
-既定のインストール先は、現在のプロジェクトの`.github/skills/consulting-analyst`、`.github/skills/tech-writer`、`.github/skills/japanese-prose`、`.github/skills/presentation-planner`です。スキルを1つだけインストールする場合や、対応している別のディレクトリを使用する場合は、次のように指定します。
+既定のインストール先は、現在のプロジェクトの`.github/skills/`です。
+consulting-analyst、tech-writer、japanese-prose、obsidian-vault、presentation-plannerをそれぞれのサブディレクトリに配置します。
+スキルを1つだけインストールする場合や、対応している別のディレクトリを使用する場合は、次のように指定します。
 
 ```bash
 npx kotonoha install --skill consulting-analyst

package/README.md

@@ -9,6 +9,8 @@ technical documents without losing the reader. `japanese-prose` improves
 Japanese wording with GiNZA-based diagnostics. `presentation-planner` turns
 source material into a reusable presentation scenario, slide outline, design
 specification, and handoff for a dedicated PPTX creation skill.
+The `obsidian-vault` skill applies scoped Vault conventions and link diagnostics
+and saves new or proofread notes only after explicit plan approval.
 
 [English](./README.md) | [日本語](./README-ja.md)
 
@@ -54,8 +56,8 @@ review.
   descriptions/commit messages/issue reports, release notes, user manuals,
   code comments, requirements definitions, system designs, test plans,
   operations runbooks, migration plans, security designs, technical proposals,
-  Blueprints, White Papers, RFI/RFP procurement documents, and Qiita/Zenn
-  articles
+  Blueprints, White Papers, RFI/RFP procurement documents, Obsidian notes
+  and templates, and Qiita/Zenn articles
 - Doctype-specific structure and checklists to guide writing
 - Original GiNZA-based `japanese-prose` lint, reading-load review, terminology
   checks, and iterative prose optimization without changing IDs, facts,
@@ -95,16 +97,47 @@ review.
 | Evidence-led publication | Technical or business White Paper | `white-paper` |
 | Request for information | RFI | `rfi` |
 | Request for proposal | RFP | `rfp` |
+| Vault knowledge note | Obsidian note or reusable template | `obsidian` |
 | Technical article | Zenn article | `zenn` |
 | Technical article | Qiita article | `qiita` |
 
 Reusable templates are included for README, design decisions, user manuals,
 PR descriptions, requirements definitions, system designs, test plans,
 operations runbooks, migration plans, security designs, technical proposals,
-Blueprints, White Papers, RFI, RFP, and Qiita articles. Every supported
+Blueprints, White Papers, RFI, RFP, Obsidian notes, and Qiita articles. Every supported
 doctype includes dedicated structure guidance and a review checklist under
 `skills/tech-writer/references/doctypes/`.
 
+For Obsidian, copy
+[`obsidian.md`](skills/tech-writer/assets/templates/obsidian.md) into your
+vault's template folder and select that folder in the core Templates plugin.
+Create and name an empty note, then run **Templates: Insert template**.
+The template includes YAML properties, core title/date variables, wikilinks,
+a callout, and a task; no community plugins are required. Kotonoha does not
+configure your vault. See the [Obsidian guide](skills/tech-writer/references/doctypes/obsidian.md)
+for setup, placeholder handling, and limitations.
+
+## Working with an Obsidian Vault
+
+Use the dedicated `obsidian-vault` skill for Vault conventions, note creation,
+related-note proposals, internal-link diagnosis and Japanese proofreading.
+Its local CLI requires Linux, CPython 3.12 and uv; it does not require
+Obsidian, MCP or plugins. Install `tech-writer` and `japanese-prose` alongside
+it for creation and proofreading, or install all skills.
+
+The user explicitly selects the Vault, read scopes and model-context consent.
+Only `apply` writes a single approved `.md` note; a hash-bound plan, protected
+syntax checks and an exact semantic review are required for changed edits.
+Unresolved links are observations, not automatic repair requests.
+Runtime commands use `uv run --offline --locked --python 3.12`; dependency
+bootstrap needs separate consent. See the [Japanese workflow guide](skills/obsidian-vault/references/workflow.md)
+for requests, command examples, data retention and recovery.
+
+Saving is limited to verified local filesystems and conservatively refuses
+symlinks, unsupported ownership/modes, multiple hard links and all xattrs,
+including SELinux labels. Post-check external edits and LLM mistakes cannot
+be eliminated. The skill is not a host sandbox.
+
 ## What consulting-analyst does
 
 - Defines the decision-maker, decision question, outcome, scope, and evidence
@@ -155,7 +188,8 @@ handoff without inventing missing evidence.
 
 - GitHub Copilot CLI installed
 - Python 3.9+ for tech-writer's structural lint
-- Python 3.10+ and `uv` for the bundled GiNZA diagnostics such as prose lint,
+- Python 3.10+ and `uv` for the edit-invariant gate and bundled GiNZA
+  diagnostics such as prose lint,
   reading-load analysis, outline extraction, and terminology checks; `uv`
   resolves GiNZA, `ja_ginza`, and spaCy on first use
 
@@ -173,7 +207,7 @@ npx kotonoha install
 
 `kotonoha install` installs every packaged skill that is not already present.
 The following commands install `consulting-analyst`, `tech-writer`,
-`japanese-prose`, and `presentation-planner` into `.github/skills/`:
+`japanese-prose`, `obsidian-vault`, and `presentation-planner` into `.github/skills/`:
 
 ```bash
 npm install --save-dev kotonoha
@@ -181,12 +215,13 @@ npx kotonoha install --skill all
 ```
 
 `--skill all` is the default, so `npx kotonoha install` has the same behavior.
-Confirm that all four skills were installed:
+Confirm that all five skills were installed:
 
 ```bash
 test -f .github/skills/consulting-analyst/SKILL.md
 test -f .github/skills/tech-writer/SKILL.md
 test -f .github/skills/japanese-prose/SKILL.md
+test -f .github/skills/obsidian-vault/SKILL.md
 test -f .github/skills/presentation-planner/SKILL.md
 ```
 
@@ -209,6 +244,20 @@ scratch for kotonoha and does not include `natural-japanese` source code.
 GiNZA dependency and license information is recorded in
 `skills/japanese-prose/NOTICE.md`.
 
+The lint also flags adjacent duplicate particles/words, Japanese bracket
+mismatches, and polite/plain style mixing within a paragraph. Findings are
+review targets, not automatic replacements. Use `proofread` mode for minimal
+typo/grammar corrections without optional stylistic rewriting. The 0–100
+score is a triage aid, not correction accuracy or a quality certificate.
+
+Before editing, the workflow saves an immutable original. The bundled
+`scripts/invariants.py` checks protected content and requires a hash-bound
+semantic review of changed prose. Numbers, identifiers, code, tables, links,
+and caller-supplied proper names/domain terms cannot be silently changed.
+Mechanical equality alone does not establish preserved meaning. See
+[`review-workflow.md`](skills/japanese-prose/references/review-workflow.md)
+for the review format and gate exit codes.
+
 You do not need to name GiNZA explicitly in a natural-language request.
 Requests to make a Japanese document more natural, readable, concise, or less
 formulaic invoke the bundled prose-optimization workflow. For example:
@@ -225,6 +274,7 @@ and repetitive AI-like phrasing, then fix the findings.
 You can specify the intended mode more precisely:
 
 - Edit the file: `Optimize the Japanese prose in README-ja.md.`
+- Correct errors only: `Proofread README-ja.md; make minimal typo/grammar corrections without stylistic rewrites.`
 - Review without editing: `Review the Japanese in README-ja.md, but do not modify the file.`
 - Score only: `Score the Japanese prose in README-ja.md out of 100.`
 - Run every diagnostic: `Run the full Japanese prose optimization workflow on README-ja.md.`

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "kotonoha",
-  "version": "0.3.0",
-  "description": "GitHub Copilot CLI skills for consulting analysis, technical writing, Japanese prose, and PPTX planning.",
+  "version": "0.4.1",
+  "description": "GitHub Copilot CLI skills for consulting analysis, technical writing, Japanese prose, Obsidian vaults, and PPTX planning.",
   "license": "MIT",
   "author": "nahisaho",
   "repository": {
@@ -17,7 +17,8 @@
   },
   "scripts": {
     "test": "node --test",
-    "test:ginza": "uv run skills/japanese-prose/scripts/test_engine.py"
+    "test:ginza": "uv run skills/japanese-prose/scripts/test_engine.py",
+    "test:obsidian-vault": "uv run --offline --locked --python 3.12 skills/obsidian-vault/scripts/test_vault.py"
   },
   "engines": {
     "node": ">=18"
@@ -32,6 +33,7 @@
     "strategy",
     "documentation",
     "markdown",
+    "obsidian",
     "presentation",
     "pptx",
     "powerpoint",

package/skills/japanese-prose/NOTICE.md

@@ -1,4 +1,4 @@
-# GiNZA dependency notice
+# Diagnostic dependency notices
 
 This skill is an original kotonoha implementation and does not include source
 code from `coji/natural-japanese`.
@@ -15,3 +15,9 @@ datasets.
 The implementation targets GiNZA 5.2.x and uses token surface forms, lemmas,
 universal part-of-speech tags, dependency relationships, sentence boundaries,
 and named-entity labels.
+
+The edit-invariant gate uses
+[markdown-it-py](https://github.com/executablebooks/markdown-it-py), distributed
+under the MIT License, to parse Markdown without treating short fences
+inside longer fenced code blocks as prose. Its dependencies are resolved by
+`uv` when `scripts/invariants.py` is run.

package/skills/japanese-prose/SKILL.md

@@ -6,10 +6,10 @@ description: >-
   reviewing, or scoring Japanese prose; when the user asks for more natural,
   readable, concise, or less AI-like Japanese; or when tech-writer delegates
   its sentence-level quality pass. Owns wording, sentence rhythm, reading
-  load, terminology review, and formulaic-expression detection. Does not own
-  technical-document structure or presentation storylines.
+  load, typo and grammar review, terminology, and edit-invariant checks.
+  Does not own technical-document structure or presentation storylines.
 license: MIT
-argument-hint: "[write|review|score] [quick|full] <target file or request>"
+argument-hint: "[write|proofread|review|score] [quick|full] <target file or request>"
 ---
 
 # japanese-prose
@@ -39,6 +39,8 @@ acceptance criteria, approval states, or normative force.
 - `write`: write or rewrite Japanese prose. Use `quick` unless the document
   is external-facing, high-risk, or longer than roughly 10,000 Japanese
   characters.
+- `proofread`: correct demonstrable typos and grammatical errors with minimal
+  edits. Do not perform optional stylistic rewrites or chase a higher score.
 - `review`: report problems and proposed corrections without editing.
 - `score`: run diagnostics and report the 0–100 score without rewriting.
 - `quick`: run prose lint once, review findings in context, edit, and rerun
@@ -50,33 +52,57 @@ acceptance criteria, approval states, or normative force.
 ## Workflow
 
 1. Read the target, audience, intended outcome, and calling skill's frozen
-   invariants.
+   invariants. Before editing, save an immutable copy of the entire original
+   file as `<workdir>/prose-original.md`. Keep this separate from diagnostic
+   baselines, which may change between rounds.
 2. Read `references/writing-guidelines.md` before generating or rewriting
-   prose.
+   prose. Resolve `<japanese-prose-dir>` to the directory containing this
+   loaded skill; do not assume the shell is running in that directory.
 3. Run the GiNZA prose diagnostic:
 
    ```bash
-   uv run scripts/lint.py <target-file> --genre tech --json > <workdir>/prose-baseline.json
+   uv run <japanese-prose-dir>/scripts/lint.py <target-file> --genre tech --json > <workdir>/prose-baseline.json
    ```
 
 4. For `full` mode, also run:
 
    ```bash
-   uv run scripts/lint.py <target-file> --genre tech --reading-load --json
-   uv run scripts/outline.py <target-file>
-   uv run scripts/terms.py <target-file> --json
+   uv run <japanese-prose-dir>/scripts/lint.py <target-file> --genre tech --reading-load --json
+   uv run <japanese-prose-dir>/scripts/outline.py <target-file>
+   uv run <japanese-prose-dir>/scripts/terms.py <target-file> --json
    ```
 
-5. Classify each finding as `fix` or `keep`. A detector identifies a review
-   target; it does not authorize blind replacement.
-6. Apply only fixes that improve the intended reader's understanding while
-   preserving the frozen invariants.
+5. Read the entire prose for typos, particle errors, subject/predicate
+   mismatches, and incorrect inflections even when lint reports no findings.
+   Classify each finding as `fix` or `keep`. A detector identifies a review
+   target; it does not authorize blind replacement. Adjacent duplicate
+   particles/words, Japanese bracket mismatches, and within-paragraph style
+   mixing are proofreading targets, not proof of an error.
+6. Correct demonstrable errors first. In `write` mode, then consider optional
+   wording changes that serve the reader's stated goal. Keep these separate
+   from necessary corrections. Preserve acceptable wording when a change
+   merely substitutes a synonym or removes a legitimate qualification.
+   Never infer a factual or proper-name correction from plausibility alone.
 7. Rerun the prose diagnostic with
    `--baseline <workdir>/prose-baseline.json` to classify new, persisting,
    and resolved findings. Replace the baseline only after recording the
    decisions for the current round.
-8. Stop when every finding has a decision, no new actionable finding appears,
-   and the document passes the checks in `references/review-workflow.md`.
+8. Run the edit-invariant gate against the immutable original:
+
+   ```bash
+   uv run <japanese-prose-dir>/scripts/invariants.py <workdir>/prose-original.md <target-file> --protect <proper-name-or-domain-term> --json
+   ```
+
+   Repeat `--protect` for each frozen proper name or domain term; omit it only
+   when there are none. Exit 2 blocks changed protected content. Any edit
+   requires a contextual semantic review, even if all mechanical checks
+   pass: exit 3 means that review is pending or rejected, not completion.
+   Follow `references/review-workflow.md` to record the hash-bound review,
+   then rerun with `--review <workdir>/semantic-review.json --json`.
+   Recheck after every subsequent edit; a stale review cannot approve it.
+9. Stop only when every finding has a decision, no new actionable finding
+   appears, and the invariant gate returns `passed`. If the gate cannot run,
+   report the failure rather than declaring completion.
 
 Allow at most three edit-and-diagnose rounds per invocation. If actionable
 findings or invariant violations remain, report that the optimization did not
@@ -108,4 +134,7 @@ Report:
 - findings fixed and findings deliberately kept
 - any skipped diagnostic and its reason
 - invariant verification result
+- necessary corrections versus optional wording changes
+- semantic review status and any remaining uncertainty; mechanical equality
+  is not a guarantee of preserved meaning
 - `completed` or `did not converge`

package/skills/japanese-prose/references/review-workflow.md

@@ -40,6 +40,61 @@ Read only headings and paragraph openings. The argument must still be
 predictable. Then read the finished prose continuously and verify that local
 rewrites did not damage transitions or create repeated explanations.
 
+## Require a semantic review of edits
+
+Run `scripts/invariants.py` on the immutable pre-edit file and the edited
+file. It protects numbers and known quantity units in occurrence order,
+uppercase identifiers, URL/link destinations, frontmatter, heading levels,
+inline code, fenced/indented code, Markdown tables, HTML, and caller-supplied
+`--protect` terms. The Markdown parser recognizes nested and long fences.
+The check is conservative: it may block a legitimate reorder or protected
+content correction. Such changes need separate authorization, not a
+reviewer override of a failed invariant.
+
+Mechanical equality cannot establish equivalent meaning. For every changed
+passage, compare the original and edited text, including nearby context:
+
+- `actors`: who performs or receives each action is unchanged
+- `negation`: polarity and the scope of negation are unchanged
+- `conditions`: prerequisites, exceptions, acceptance criteria, and approval states are unchanged
+- `modality`: obligations, recommendations, permissions, and uncertainty are unchanged
+- `scope`: limitations such as 「だけ」「すべて」「少なくとも」 are unchanged
+- `causality`: causal and temporal relationships are unchanged
+- `quantity_bindings`: each quantity still refers to the same object or action
+- `terminology`: proper names and domain concepts are unchanged
+- `structure`: section identity, order, quoted meaning, and traceability are unchanged
+
+Record the review as JSON. Copy `before_sha256` and `after_sha256` from the
+gate output, identify the actual reviewer, and set a check to `true` only
+after inspecting it. Do not infer approval from a score, an unchanged token
+count, or the absence of warnings. A review can be performed by the agent or
+a human, but an agent review is not a human approval or a semantic proof.
+
+```json
+{
+  "before_sha256": "<hash from the gate>",
+  "after_sha256": "<hash from the gate>",
+  "reviewer": "<actual reviewer identifier>",
+  "checks": {
+    "actors": false,
+    "negation": false,
+    "conditions": false,
+    "modality": false,
+    "scope": false,
+    "causality": false,
+    "quantity_bindings": false,
+    "terminology": false,
+    "structure": false
+  }
+}
+```
+
+Rerun the gate with `--review <review-file>`. Exit codes are 0 for `passed`,
+1 for input/runtime errors, 2 for protected-content violations, and 3 for
+missing, stale, incomplete, or rejected semantic reviews. Subsequent edits
+invalidate the review. If equivalence is uncertain, keep the original
+wording or report the unresolved concern.
+
 ## Convergence
 
 The review is complete when:
@@ -47,4 +102,6 @@ The review is complete when:
 - every finding has a `fix` or `keep` decision
 - rerunning diagnostics produces no new actionable finding
 - frozen invariants match the pre-edit document
+- `scripts/invariants.py` returns `passed` with a current semantic review
+  for changed text
 - the reader can reach the requested outcome without an unstated inference

package/skills/japanese-prose/references/scoring.md

@@ -22,3 +22,9 @@ A high score does not prove that facts are correct, the argument is complete,
 or the prose is natural. A low score does not require every finding to be
 changed. Always report the finding categories and contextual decisions beside
 the score.
+
+Proofreading findings and style/readability findings contribute to the same
+triage score, but they are not interchangeable measures of quality. Report
+the categories separately. Do not use this score as typo-detection recall,
+correction accuracy, semantic fidelity, or evidence that an LLM-assisted
+rewrite is better. A correctly repaired typo may leave the score unchanged.

package/skills/japanese-prose/scripts/core.py

@@ -76,10 +76,14 @@ def iter_content_lines(text: str) -> Iterable[tuple[int, str]]:
 
         fence = FENCE_RE.match(raw)
         if fence:
-            marker = fence.group(1)[0]
+            marker = fence.group(1)
             if not fence_marker:
                 fence_marker = marker
-            elif marker == fence_marker:
+            elif (
+                marker[0] == fence_marker[0]
+                and len(marker) >= len(fence_marker)
+                and not raw[fence.end():].strip()
+            ):
                 fence_marker = ""
             yield index, ""
             continue