Slipmark

Slipmark

Reply Intelligence Group のプロジェクトです。

AI エージェントが何を確認したか、証明できるようにします。

ワークフローに追加します。

- uses: actions/checkout@v4
- uses: founder-ship-it/[email protected]
  with:
    require: |
      specs/your-spec.md

エージェントが承認した後にファイルが変更されると、ビルドは拒否されます。

Slipmark verify: 1 verified · 1 refused

  ✓ verified             review-agent verified examples/attestation/brief.md
  ✗ hash_mismatch        security-audit-agent gave "cleared" for a different version of
                         examples/attestation/spec.md. The file changed after the verdict.

npx slipmark init を実行するだけでセットアップできます。コーディングエージェントはその後、slipmark attest で承認を記録します（コーディングエージェントとの連携を参照）。モデル呼び出しもアカウントも不要で、必要なのは GitHub Action ひとつです。

スリップマークとは、ボルトを締めて確認したあとに、技術者が引く塗料の線です。ボルトが少しでも動けば線が途切れ、誰もがそれに気づけます。Slipmark は AI エージェントの判定に対して同じことを行います。エージェントがファイルを承認した後に変更があると、そのマークは無効になります。

エージェントはコードをレビューし、仕様を監査し、自分の作業を承認するようになりました。弱点はその判定です。エージェントが「合格」と報告したファイルが、その後変更されていたり、そもそも確認されていなかったりしても、後続の工程ではそれを検知できません。

Slipmark は次の 2 つを行います。

1. 判定の証明。 すべてのエージェントの判定を、エージェントが読み込んだ正確なファイルの SHA-256 ハッシュに紐付けます。リリース前にゲートがファイルを再ハッシュします。不一致、ファイルの欠落、不合格の判定、または証明がまったくない場合は、拒否されます。決定論的に動作し、モデル呼び出しは不要で、GitHub Action はひとつです。
2. ドリフトの診断。 AI 機能の動作を「ロック」します。変更によってロックが破られると、Slipmark は原因として考えられるものと、その確信度を示します（確信がない場合に、確信があるように装うことはありません）。さらに、修正用のプロンプトをコーディングエージェントに渡します。

ステータス：v0.7.0、初期段階です。Apache-2.0。任意のホステッドレイヤー：Slipmark Cloud。

ゲートが必要な理由

私たちは毎晩、調査、アーキテクチャ、セキュリティ監査、ビルド、QA を担当する 20 以上のエージェントからなるパイプラインを実行しています。毎朝、エージェントは何が合格したかを報告していました。

ところが、最終検証ジョブが数か月にわたり、誤ったブランチをチェックしていたことがわかりました。失敗しようがなかったため、実際に失敗することもありませんでした。何かを証明しているわけではないのに、何か月も緑のチェックマークが表示されていたのです。

そこで私たちはゲートを構築しました。すべての判定を、読み込んだ内容のハッシュに紐付け、リリース前に再確認します。23 件のオープンなエージェントのプルリクエストに適用したところ、23 件すべてを拒否しました。

Slipmark が証明すること、証明しないこと

Slipmark はエージェントが正しいかどうかを判断しません。信頼しようとしている判定が、リリースするコードに対するものかを確かめます。

証明すること：

• 判定は、これらのバイト列そのものに対して行われたこと。ひとつでも変更すると、その判定は無効になります。
• 必須とするすべてのファイルに、最新の合格判定があること。判定がない場合は、黙って合格とするのではなく、拒否されます。
• 毎回同じ結果が得られること。モデル呼び出しも、スコアリングも、判断もありません。

証明しないこと：

• エージェントが賢かったかどうか。エージェントが初日にバグを見落とした場合、そのファイルに変更がない限り、Slipmark は合格にします。それがエージェントの判定であり、Slipmark はそのまま保持します。
• 署名されていない証明を誰が作成したか。プッシュできる人なら誰でも、"by": "security-reviewer" と記述できます。署名付き判定を必須にすれば、信頼するワークフローによって署名された判定だけが有効になります。

そのため、すでに信頼しているチェックと組み合わせてください。Slipmark は判定に対するロックであり、判定そのものではありません。より強い判定が必要な場合は、変更されたすべてのファイルを網羅すること、Slipmark 自身が実行するチェック、モデル変更時の再レビューなど、より多くの条件を必須にします。これらは現在 main にあります（docs/attestation.md）。機密性の高いパスに対する独立したレビュアー 2 名と、attestation v2 の残りの機能は、次の予定です。

クイックスタート

保護するリポジトリ内で（Node 22.6 以降）：

npx slipmark init

  + create .slipmark/attestations/.gitkeep      attestation directory, committed with the repo
  + create .github/workflows/slipmark.yml       report-only gate on pull requests
  + create AGENTS.md                            agent instructions for attesting verdicts
  ~ update CLAUDE.md                            agent instructions for attesting verdicts

セットアップはこれで完了です。

• プルリクエストごとにゲートを実行するワークフロー。まだ判定がないリポジトリでは失敗してしまうため、最初はレポートのみのモードで開始します。エージェントが証明を記録するようになったら、fail-on-refusal: "true" を設定してください。
• AGENTS.md に加え、リポジトリにすでにある場合は CLAUDE.md、Cursor のルール、Copilot の指示に記載するエージェント向けの指示。init を再実行すると、該当ブロックのみが更新され、これらのファイルのほかの部分には一切触れません。

いつでも npx slipmark verify で確認できます。.slipmark/attestations/ をコミットしてください。

コーディングエージェントでの利用

init が書き込む指示だけで、エージェントは自力で証明を記録できます。Slipmark には触れず、新しいリポジトリで Claude Code に簡単なレビュータスクを依頼してみました。

specs/invoice-export.md に照らして src/export.ts をレビューしてください。仕様を満たしていますか？

Claude Code は両方のファイルを読み、エクスポート形式が CSV ではないことを見つけ、次のように記録しました。

{
  "by": "reviewer",
  "verdict": "fail",
  "subjects": [
    { "path": "src/export.ts", "sha256": "0ea6029f…" },
    { "path": "specs/invoice-export.md", "sha256": "81994e0f…" }
  ],
  "note": "Tenant filter and 10k limit OK; no CSV output, returns raw query result"
}

レビュー対象のファイルだけでなく、判定の根拠となった両方のファイルが記録されています。コードを修正すると、エージェントが再び読み取るまで、古い判定は有効ではなくなります。

Claude Code、Cursor、Copilot、Codex のセットアップについては、docs/agents.md をご覧ください。

Claude Code プラグイン

Claude Code にはプラグインもあります。リポジトリの指示がなくても Claude が判定を記録できるようスキルを追加するほか、/slipmark:verify と /slipmark:setup コマンド、および承認済みのファイルがその後変更された場合に、Claude に再読込と再証明を求める停止チェックを追加します。

/plugin marketplace add founder-ship-it/Slipmark
/plugin install slipmark@slipmark

実行内容の詳細は、claude-plugin/ をご覧ください。

MCP サーバー：Codex、Cursor、Copilot、Gemini

slipmark mcp は slipmark_attest と slipmark_verify を MCP ツールとして提供するため、MCP に対応するあらゆるエージェントが判定を記録・確認できます。OpenAI Codex の場合は、~/.codex/config.toml に次のように設定します。

[mcp_servers.slipmark]
command = "npx"
args = ["-y", "[email protected]", "mcp"]

Claude Code、Cursor、VS Code の Copilot、Gemini CLI のセットアップについては、docs/mcp.md をご覧ください。エージェントはこれを通じて人間の承認を記録できません。

判定の証明

1. エージェントが読み取った内容を証明します。 判定を下すエージェントの各ステップの最後に、次を呼び出します。

slipmark attest --by security-audit-agent --verdict cleared \
  --subject specs/invoice-export.md --subject src/export.ts

.slipmark/attestations/<agent>--<file>.json が書き込まれます。

{
  "schema": "slipmark/attestation@1",
  "by": "security-audit-agent",
  "verdict": "cleared",
  "at": "2026-10-17T09:00:00.000Z",
  "subjects": [
    { "path": "specs/invoice-export.md", "sha256": "cf89da70…" }
  ]
}

2. ゲートは、何かがリリースされる前に証明を確認します。

slipmark verify --require specs/invoice-export.md

結果	意味
verified	合格の判定であり、ファイルはエージェントが確認したときとバイト単位で完全に一致しています
hash_mismatch	判定後にファイルが変更されています。判定対象は別のファイルです。
subject_missing	証明対象のファイルが存在しなくなっています
verdict_not_passing	エージェントが失敗またはブロックと判定しました
unattested	--require で指定されたファイルに、現在有効な合格判定がないか、証明がまったくありません
invalid	証明の形式が不正であるか、リポジトリ外のパスです

合格判定は pass と cleared です。ゲートに該当するものがない場合は拒否となり、暗黙に合格することはありません。ほかのツール向けに完全なレポートを出力するには、--json を指定します。

より強力な判定（main 上、未リリース）。判定の検証対象を記録し、Slipmark 自身にチェックを実行させます。

slipmark attest --by reviewer --verdict pass --subject src/export.ts \
  --against specs/invoice-export.md --run "npm test"

--run が失敗した場合、合格判定は拒否されます。次に、指定したファイルだけでなく、変更されたすべてのファイルに判定を必須にします。

slipmark verify --coverage diff --base origin/main

詳細は docs/attestation.md をご覧ください。

エージェントのコンテキスト

レビュアーはコードを承認しました。しかし、レビュアーへの指示を書いたのは誰でしょうか？ 2026 年のコーディングエージェントへの攻撃では、レビュー対象のコードには手を加えず、AGENTS.md、スキル、MCP の設定が変更されました。.slipmark/policy.json に "context": {} を追加すると、Slipmark は各判定をエージェントへの指示にもひも付けます。

• 後から指示が変更された場合、その指示のもとで行われた判定は無効になります
• AGENTS.md、CLAUDE.md、スキル、または MCP の設定を変更するには、承認者の判定が必要です（CODEOWNERS と併用するか、署名付き承認を必須にします）
• 変更された指示は、GitHub で全体が表示されるプレーンな Markdown でなければなりません。許可リストにないもの（HTML、コメント、画像、図、GitHub が後から追加するものなど）はすべて拒否されます。また、GitHub Actions では各ファイルを GitHub 独自のレンダラーで検証します
• 監視対象外のファイルへリンクするコンテキストファイルは拒否されます

ポリシーはベースブランチから読み込まれるため、プルリクエストでこれを無効にすることはできません。現時点で対象外の事項はドキュメントに記載されています。詳しくはdocs/attestation.mdをご覧ください。

実際の攻撃パターン 5 件（Ghostcommit、Deadbugz、隠しコメント、不可視の Unicode、チェックを無効にするプルリクエスト）が拒否される様子を、slipmark-context-demoのオープンなプルリクエストでご覧ください。

署名付き判定

判定の対象だけでなく、誰が判定したのかを証明します（main 上、未リリース）。GitHub Actions のジョブでレビュアーエージェントを実行し、証明とともに署名します。

slipmark attest --by security-reviewer --verdict pass --subject src/auth/session.ts --sign

判定には、ジョブ独自の GitHub ID を使ってSigstoreで署名します。鍵の管理は不要で、すべての署名が公開透明性ログに記録されます。次に、信頼するワークフローからの判定だけを有効にします。

- uses: founder-ship-it/Slipmark@main
  with:
    require-signed: "true"
    trusted-signers: |
      https://github.com/acme/api/.github/workflows/agent-review.yml@refs/heads/main

手入力された判定、別のワークフローが作成した判定、署名後に編集された判定は拒否されます。信頼する ref などの詳細は、docs/attestation.mdをご覧ください。

GitHub Action として使用する場合：

- uses: actions/checkout@v4
- uses: founder-ship-it/[email protected]
  with:
    require: |
      specs/invoice-export.md

段階的に導入しますか？fail-on-refusal: "false" を設定すると、拒否を警告として報告し、ビルドは失敗しません。どちらの場合も、ステップの result 出力は passed または refused になります。

フォーマッター。 フォーマッターを実行するとバイト列が変わるため、ほかの変更と同様に判定が無効になります。エージェントが証明する前に（pre-commit フックの最初に）フォーマッターを実行すれば、ほとんどの場合この問題は解消されます。フォーマットの差異を許容するハッシュモードと、差分のみを再レビューする機能は v0.5 で予定されています。

マージする予定のブランチで実行してください。ブランチ名ではなく内容を検証するため、あるブランチで生成された判定で別のツリーを承認することはできません。

詳しくはdocs/attestation.mdをご覧ください。

Slipmark Cloud

上記のゲートは無料のオープンソースで、アカウントも不要です。Slipmark Cloudは、ビルド結果だけでなく記録も必要とするチーム向けの、任意のホスト型レイヤーです。

• すべての実行を記録する、追記専用のハッシュチェーン台帳。各実行に証明ページがあります。記録は編集も削除もできません。また、チェーンのヘッドは毎日Sigstoreの公開Rekorログに公開されるため、履歴が書き換えられていないことを誰でも確認できます。
• CIの報告をそのまま信頼しません。 CloudはGitHub独自のコミットコピーからアテステーションとアテステーション対象ファイルを再読み込みし、すべての結果を改めて算出します。
• 必須チェックとしてのルール。 たとえば、「src/auth/**配下の変更には、security-reviewerによる合格判定が必要」というルールを、プルリクエストにSlipmark policyとして投稿します。管理者は不合格のチェックを承認できますが、その理由を記録に残す必要があります。
• 対応方法がわかるアラート。 Slack、Microsoft Teams、Discord、Google Chat、PagerDuty、メール、または任意のサービス向け署名付きウェブフック（Standard Webhooks）に通知できます。各失敗にはルール、ファイル、承認が必要なエージェント、修正コマンドが明記されます。リポジトリやルールごとに振り分けて、適切な担当者に通知できます。プルリクエストが合格すると、PagerDutyのインシデントは自動的にクローズされます。
• Slipmark Slackアプリ。 プルリクエストごとにスレッドを作成し、管理者はSlackから不合格のチェックを承認できます。承認理由は記録に残ります。
• 実行数、ブロックされたプルリクエスト数、検出された古い判定、すべての例外承認をまとめた週次サマリー。
• SOC 2 CC8.1およびISO 27001の変更管理統制に関するインサイトと監査証跡パック。監査人向けPDFにJSONが添付されます。

Slipmark GitHub Appをインストールし、ワークフローに2行追加するだけで有効になります。

jobs:
  verify:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # GitHub signs a token saying which repo and run this is. No API key.
    steps:
      - uses: actions/checkout@v4
      - uses: founder-ship-it/[email protected]
        with:
          cloud: "true"

cloudによってゲートの判定結果が変わることはありません。ゲート自体は、パブリック・プライベートを問わず、すべてのリポジトリで無料です。Cloudはパブリックリポジトリでは無料です。プライベートリポジトリはTeamプランで1シートあたり月額£15（最低3シート）で、14日間の無料トライアルがあります。クイックスタートと料金をご覧ください。

ドリフト診断の違い

多くのAI評価・可観測性ツールは検出（出力のスコアリング、リグレッションの警告、ダッシュボードの表示）に重点を置いています。Slipmarkならではの特徴は診断と修復であり、確実性について意図的に誠実な設計になっています。

確信度は推測ではなく、根拠から導きます——確実性を3段階で正直に制限します：

利用可能な証拠	確信度の上限	意味
署名／パターンのみ	0.40（低／中）	ヒューリスティックであり、証明ではありません — investigate_first
＋実行トレース	0.69（中）	仕組みはわかりますが、コミットは特定できません
＋git diff または二分探索で特定したコミット	上限なし（高まで）	因果関係を示す証拠により、特定の変更との関連を確認できます

• 精度を偽りません。 確信度が低い場合、ランク付けしたファイルを一切提示せず、明示的な調査モード（「盲目的に修正を適用しないでください」）に切り替わります。
• 修復プロンプトはモードによって制御されます — suggest_patch（高）、minimal_fix（中）、investigate_first（低） — これにより、エージェントには適切な裁量が与えられます。
• 不正な操作への対策： すべてのプロンプトで、合格を強制するためにロックファイルやフィクスチャを編集することを禁止しています。

得られた因果関係の証拠

証拠がある場合、Slipmark は推測ではなく、決定的な証拠を提示します。

• 実行トレース — ロック自体が計測を行い（実行されたモジュール／シンボルや、intentSourceUsed="first" のような観測結果など）、コードが実際に行ったことに基づいて診断します。
• 二分探索 — bisectFirstFailing() は、実際の「AI の動作に対する git bisect」です。コミット履歴とプローブを指定すると、約 log₂(n) ステップで問題のコミットを二分探索します。ホスト側がプローブ（チェックアウトして再実行）を提供し、エンジンがアルゴリズムを担います。
• 監視対象シンボルの変更 — ロックは、不変条件が依存するシンボルを宣言します。差分でそのうちの一つが変更されていれば、動作の背後にある特定のコードが変わったという、裏付けのある証拠になります。

ドリフトのデモ

デモ（packs/demo-shop）は、エンジンの汎用性を示すために、意図的に元の製品とは異なるeコマースサポート用アシスタントです。Slipmark が回帰を検出して診断する様子を確認できるよう、回帰を一つ仕込んであります。

Slipmark — pack `demo-shop`
  1 passed · 1 drifted · 0 errored (of 2)
  ✗ shop.latest_intent_wins — drift
      cause: Likely: stale intent carryover …  Probable hot-spot: `…/shopAssist.ts` (85% relevance).
      confidence: high (86%) · severity: high · mode: suggest_patch

packs/demo-shop/shopAssist.ts の PLANTED_BUG を false にすると、ロックが緑色になります。

仕組み

locks (your behavioral invariants)
   │  run() → pass / drift + failed assertions
   ▼
engine
   ├─ signatures      match the failure to a known drift pattern   (pack-supplied)
   ├─ scorer          rank changed files + modules by relevance
   ├─ confidence      structured score + honesty caps + tier-gating
   └─ repairPlan      mode-gated, coding-agent-ready repair prompt
   ▼
DriftAnalysisReport  (cause, ranked files/modules, confidence, repair prompt)

ロックの作成 — 2つの方法

1. 設定のみ（JSON、コード不要） — 最も手軽な方法

プレーンな JSON でパックを定義し、各ロックの対象コマンドとして AI の出力を返すコマンドを指定します。Slipmark は標本を標準入力で渡してコマンドを実行し、標準出力を検証します。システムで使われている言語は問いません。

{
  "id": "my-product",
  "locks": [{
    "key": "support.latest_intent_wins",
    "scope": "ai",
    "invariants": ["When the user pivots topic, the reply addresses the latest intent."],
    "failureSignatures": ["stale_intent_carryover"],
    "watchedSymbols": ["composeReply"],
    "target": { "command": "node assistant.mjs", "inputFormat": "stdin-json" },
    "fixture": { "turns": [/* ... */] },
    "assertions": [
      { "name": "focuses_on_latest_intent", "type": "matches", "value": "track|delivery" },
      { "name": "no_prior_intent_carryover", "type": "not_matches", "value": "return|refund" }
    ]
  }]
}

slipmark ./drift.pack.json --emit .slipmark

アサーションの種類は contains、not_contains、matches、not_matches、equals、not_equals です。「ゴールデンモード」（標本そのものが出力）にするには、target.command を省略します。動作する完全な例は packs/demo-shop-declarative/ を参照してください。

2. TypeScript（すべての機能を利用）

任意の検証ロジック、自己計測型の実行トレース、またはプロセス内ターゲットを使う場合は、TypeScript で Pack を定義します。

Pack — 拡張機能のすべて

エンジンはドメイン固有のものを一切インポートしません。Pack がすべてを担います。

import { definePack } from "slipmark";

export const myPack = definePack({
  id: "my-product",
  signatures: [ /* how to recognise your drift patterns */ ],
  signatureToModules: { /* signature → modules it implicates */ },
  baseConstraints: [ /* do-not-break rules injected into every repair prompt */ ],
  scopeConstraints: { /* per-scope extra constraints */ },
  scopeImpact: { /* per-scope business impact copy */ },
  signatureGoals: { /* per-signature repair goal */ },
  signatureImpact: { /* per-signature impact */ },
  diffKeywords: [ /* domain words that align a diff to behaviour */ ],
  systemMap: { modules: [ /* your module responsibilities */ ] },
  locks: [ /* your behavioral invariants */ ],
});

パックを差し替えて別の製品を指定すれば、エンジンに変更を加える必要はありません。スタンドアロンとして切り出した目的はまさにここにあります。

CLI

slipmark init [--dry-run] [--no-workflow] [--no-agents] [--force]
slipmark <pack.js> [--git <git-context.json>] [--prompts] [--emit <dir>]
slipmark attest --by <agent> --verdict <pass|cleared|fail> --subject <file>... [--note "..."] [--out <file>]
slipmark verify [--dir .slipmark/attestations] [--require <file>...] [--json]
slipmark bisect --range <git-range> --command "<probe>"
slipmark dashboard <pack> --history <h.json> --out <file.html>

いずれかのロックでドリフトまたはエラーが発生すると、ゼロ以外の終了コードを返すため、CI のゲートとして使用できます。Git のコンテキスト（前回の成功時から変更されたファイル）を渡すと、信頼度を「シグネチャのヒューリスティック」から「証拠に裏付けられた」状態へ引き上げ、優先度順のファイルを表示します。

二分探索 — 問題のコミットを見つける

エンジンには、実際の「AI の動作に対する git bisect」が組み込まれています。範囲とプローブコマンド（終了コード 0 はロック合格）を指定すると、回帰を導入したコミットを二分探索し、その後、作業ツリーを元に戻します。

slipmark bisect --range "main~30..main" \
  --command "npm run build --silent && node dist/src/cli.js dist/packs/demo-shop/pack.js"

  ✗ first failing commit: deadbeef…
    last good commit:    00aa11bb…
    probes evaluated:    5          # not 30 — ~log2(n)

二分探索で特定した問題のコミットは、Slipmark が得られる最も強力な因果関係の証拠です。これにより信頼度の上限が引き上げられ、正確なコミット範囲が修正プロンプトに反映されます。

ローカルダッシュボード

Slipmark は、ローカルの実行履歴 JSON ファイルから、実行ごとのドリフト傾向、ロックの状態、信頼度バー、詳細な修正プロンプトを表示する、単体で動作する HTML ダッシュボードを生成します。リポジトリ間で共有できるホスト型のビューについては、Slipmark Cloud を参照してください。

# Run a pack and append the result to a rolling history, then render the dashboard:
slipmark dashboard ./drift.pack.json --history .slipmark/history.json --out dashboard.html

# Or render an existing history file:
slipmark dashboard --from dashboard/sample-history.json --out dashboard/sample.html

--history ファイルには、実行履歴が時間とともに蓄積されます。レンダリング済みの例は dashboard/sample.html を参照してください。

コーディングエージェントとの連携

--emit <dir> を指定すると、失敗したロックごとに次のファイルが出力されます。

• <lockKey>.repair.md — すぐに実行できる修正プロンプト
• index.md — すべての修正へのリンクをまとめた概要
• AGENT_RULES.md — .cursor/rules/ または CLAUDE.md に追加すると、すべてのコーディングエージェントが Slipmark のプロンプトを安全に扱えるようになります（調査モードを守り、合格させるためにロックを編集せず、変更後にロックを再実行する）

プロンプトを Claude Code に渡し、ヘッドレスで実行します。

claude -p "$(cat .slipmark/shop.latest_intent_wins.repair.md)"

ここが差別化のポイントです。多くのツールは、指標が低下したことを知らせるだけです。Slipmark は、エージェントに何が原因で低下した可能性が高いか、そして安全に修正する方法を伝えます。証拠がないときは、過信して対応しないようにします。

「エリート」へのロードマップ

1. 因果関係のさらなる分析 — 実装済み。 実行トレース、実際の二分探索 （bisectFirstFailing）、変更された監視対象シンボルの分析が、根拠に基づく 3 段階の信頼度モデルに反映されるようになりました。✅
2. コーディングエージェントとの連携 — 実装済み。 --emit で修復プロンプトと AGENT_RULES を出力します。✅
3. 二分探索ホストアダプター — 実装済み。 slipmark bisect / runGitBisect は、 実際のコミットをチェックアウトしてプローブを実行し、ツリーを復元します。✅
4. セルフサービスでの作成 — 実装済み。 ターゲットコマンドと宣言的なアサーションを 含むパックをプレーンな JSON で定義できます。TypeScript は不要です。✅
5. ダッシュボードビュー — 実装済み（静的）。 ドリフトの傾向、ロックの状態、 詳細な修復プロンプトを表示する自己完結型 HTML ダッシュボードです。実行履歴の JSON を基にしています。✅
6. 判定の証明 — 実装済み。 slipmark attest / verify と GitHub Action により、エージェントの判定を SHA-256 ハッシュに紐付け、 不一致の場合は拒否します。✅
7. ホスト型クラウド（オープンコア）— 証明機能向けに実装済み。 Slipmark Cloud： 台帳、サーバー側での再検証、ルール、アラート、エビデンスパック。✅
8. 証明 v2 (次の予定)：判定を下したモデル、Slipmark 自身によるチェックの実行、 変更されたすべてのファイルのカバレッジ、機密性の高いパスでの定足数、 書式の違いを許容するハッシュモード。

Slipmark の開発

npm install
npm test              # 40 tests
npm run demo:verify   # the attestation gate refusing a stale verdict
npm run demo          # drift diagnosis on the demo pack

ドキュメント

• 判定の証明：スキーマ、ステータス、エージェントの接続方法。
• コーディングエージェント：Claude Code、Cursor、Copilot、Codex のセットアップ。
• MCP サーバー：MCP を話すあらゆるエージェント向けの slipmark mcp。
• 証明 v2（草稿）：より詳細な証明、カバレッジ、定足数、差分の再証明、人による上書き。
• ハッシュモード（草稿）：ポリシーに基づいてパスごとに選択する、書式の違いを許容するハッシュ計算。
• 概念 — メンタルモデル（ロック、パック、署名、 誠実性モデル、修復プロンプト）。
• 作成ガイド — JSON と TypeScript のパック、アサーションの 種類、二分探索の接続方法。
• コントリビューション — セットアップ、構成、必須事項。
• 変更履歴。

ライセンス

Apache-2.0。LICENSE と NOTICE をご覧ください。選択の 理由については LICENSE-OPTIONS.md をご覧ください。

---

Slipmark は、英国ワトフォードの Reply Intelligence Group が開発しています。© 2026 Reply Intelligence Group Ltd.