haechi 1.4.0 → 1.5.0

package/README.md

@@ -8,7 +8,7 @@
 [![CI](https://github.com/raeseoklee/haechi/actions/workflows/ci.yml/badge.svg)](https://github.com/raeseoklee/haechi/actions/workflows/ci.yml)
 [![license](https://img.shields.io/badge/license-Apache--2.0-blue.svg)](LICENSE)
 [![node](https://img.shields.io/node/v/haechi)](https://nodejs.org)
-[![status](https://img.shields.io/badge/status-stable%201.4-brightgreen)](docs/current/api-stability.md)
+[![status](https://img.shields.io/badge/status-stable%201.5-brightgreen)](docs/current/api-stability.md)
 
 **English** | [한국어](README.ko.md)
 
@@ -379,3 +379,5 @@ Haechi is deliberately scoped. These are real, current limitations — listed op
 1.3.1 → 1.3.3 are security-remediation and hardening **patches** (no API/config change). 1.3.1 and 1.3.2 close two external code-review rounds — proxy header-boundary credential leak, hex IPv4-mapped IPv6 SSRF, response-header/streaming bounds, and non-JSON streaming inspection (1.3.1); proxy upstream-reader cancel-on-disconnect, token-vault audit-log hygiene, and plugin IPC reply bounds (1.3.2). 1.3.3 tightens the response-direction marker skip (a model can't wrap a secret in a fake `[TOKEN:…]` to evade scanning) and adds the cosign-signed GHCR container image.
 
 1.4.0 adds the first-party authoring CLI for the signed-plugin trust gate: `haechi plugin-keygen` (Ed25519 keypair — private key `0600`, public key is the trust anchor), `plugin-sign` (signs the exact entry-file bytes; `authProvider` must declare `readsCredentials`), and `plugin-verify` (runs the runtime's verification, fail-closed, with `--allow-capability`). A new [`plugin-signing-and-trust.md`](docs/current/plugin-signing-and-trust.md) runbook covers the keygen → sign → wire `auth.plugin.trustAnchors` → verify → rotate/pin/revoke lifecycle. Additive CLI surface (a **minor** under strict semver); no config change (`configVersion` stays `1`).
+
+1.5.0 begins the **fleet-readiness** track: the audit sink and token vault gain an injectable **store seam** (`createAuditSink({ store })` / `createTokenVault({ store })` + the default `createFileAuditStore`/`createFileTokenStore`), so a shared store can back the sha256 audit hash chain and the token vault across **multiple replicas** — closing the per-process / single-writer limitations called out under [Known limitations](#known-limitations). The file-backed defaults are byte-identical, and `createJsonlAuditSink`/`createLocalTokenVault` stay as back-compat wrappers. A `haechi-store-redis` satellite (the Redis adapters for both seams) is the production consumer. Additive (a **minor**); `configVersion` stays `1`; core stays zero runtime dependency.

package/docs/current/api-stability.ko.md

@@ -29,10 +29,10 @@
 | `haechi/runtime` — `createRuntime`, `normalizeConfig` (config shape), `defaultConfig`, `loadConfig`, `writeDefaultConfig`, `isValidPort`, `DEFAULT_CONFIG_PATH` | **FROZEN** |
 | `haechi/auth` — `authProvider` 계약, `buildIdentity`, `buildExternalIdentity`, `validateLabels`, `createBearerAuthProvider`, token store (`readAuthStore`, `addToken`, `listTokens`, `revokeToken`), `DEFAULT_ALLOWED_LABEL_KEYS` | **FROZEN** |
 | `haechi/crypto` — `cryptoProvider` 계약, `assertCryptoProviderConformance`, `canonicalize`, `createLocalCryptoProvider`, `initLocalKeyFile` | **FROZEN** |
-| `haechi/audit` — audit **event schema** (§2.3), `verifyAuditChain`, `sanitizeAudit`, `createJsonlAuditSink`, `readAuditSummary`, `FORBIDDEN_KEYS` | **FROZEN** |
+| `haechi/audit` — audit **event schema** (§2.3), `verifyAuditChain`, `sanitizeAudit`, `createJsonlAuditSink`, `readAuditSummary`, `FORBIDDEN_KEYS`, 그리고 1.5.0 주입 가능한 store 시임 `createAuditSink`, `createFileAuditStore`, `buildIntegrityRecord` | **FROZEN** |
 | `haechi/policy` — `buildPolicy`, `createPolicyEngine`, `createPolicyProfiles`, `validatePolicy`, `ACTION_STRENGTH` (action ordering) | **FROZEN** |
 | `haechi/filter` — `createDefaultFilterEngine`, `detectEntry`, 그리고 **rule/detection shape** | **FROZEN** |
-| `haechi/token-vault` — `createLocalTokenVault`, `readVault`, token format, reveal-governance 계약 | **FROZEN** |
+| `haechi/token-vault` — `createLocalTokenVault`, `readVault`, token format, reveal-governance 계약, 그리고 1.5.0 주입 가능한 store 시임 `createTokenVault`, `createFileTokenStore` | **FROZEN** |
 | `haechi/protocol-adapters` — `createProtocolAdapter`, `knownProtocolAdapters`, adapter classification 계약 | **FROZEN** |
 | `haechi/plugin` — `validatePluginManifest`, `validatePluginManifestFile`, manifest schema, 1.0 signed-plugin sandbox 표면 | **FROZEN** |
 | `haechi/proxy` — `createHaechiProxy`, `assertSafeProxyBind`, `DEFAULT_PROXY_PORT` | **FROZEN BEHAVIOR + wire/contract** (사람이 읽는 log/error **텍스트**는 변경 가능) |

package/docs/current/api-stability.md

@@ -29,10 +29,10 @@ Every `package.json` `exports` subpath and the CLI is classed. There is no silen
 | `haechi/runtime` — `createRuntime`, `normalizeConfig` (config shape), `defaultConfig`, `loadConfig`, `writeDefaultConfig`, `isValidPort`, `DEFAULT_CONFIG_PATH` | **FROZEN** |
 | `haechi/auth` — the `authProvider` contract, `buildIdentity`, `buildExternalIdentity`, `validateLabels`, `createBearerAuthProvider`, the token store (`readAuthStore`, `addToken`, `listTokens`, `revokeToken`), `DEFAULT_ALLOWED_LABEL_KEYS` | **FROZEN** |
 | `haechi/crypto` — the `cryptoProvider` contract, `assertCryptoProviderConformance`, `canonicalize`, `createLocalCryptoProvider`, `initLocalKeyFile` | **FROZEN** |
-| `haechi/audit` — the audit **event schema** (§2.3), `verifyAuditChain`, `sanitizeAudit`, `createJsonlAuditSink`, `readAuditSummary`, `FORBIDDEN_KEYS` | **FROZEN** |
+| `haechi/audit` — the audit **event schema** (§2.3), `verifyAuditChain`, `sanitizeAudit`, `createJsonlAuditSink`, `readAuditSummary`, `FORBIDDEN_KEYS`, plus the 1.5.0 injectable store seam `createAuditSink`, `createFileAuditStore`, `buildIntegrityRecord` | **FROZEN** |
 | `haechi/policy` — `buildPolicy`, `createPolicyEngine`, `createPolicyProfiles`, `validatePolicy`, `ACTION_STRENGTH` (action ordering) | **FROZEN** |
 | `haechi/filter` — `createDefaultFilterEngine`, `detectEntry`, and the **rule/detection shape** | **FROZEN** |
-| `haechi/token-vault` — `createLocalTokenVault`, `readVault`, the token format, and the reveal-governance contract | **FROZEN** |
+| `haechi/token-vault` — `createLocalTokenVault`, `readVault`, the token format, and the reveal-governance contract, plus the 1.5.0 injectable store seam `createTokenVault`, `createFileTokenStore` | **FROZEN** |
 | `haechi/protocol-adapters` — `createProtocolAdapter`, `knownProtocolAdapters`, and the adapter classification contract | **FROZEN** |
 | `haechi/plugin` — `validatePluginManifest`, `validatePluginManifestFile`, the manifest schema, and the 1.0 signed-plugin sandbox surface | **FROZEN** |
 | `haechi/proxy` — `createHaechiProxy`, `assertSafeProxyBind`, `DEFAULT_PROXY_PORT` | **FROZEN BEHAVIOR + wire/contract** (human-readable log/error **text** may change) |

package/docs/current/config-version.ko.md

@@ -1,6 +1,6 @@
 # Haechi `configVersion` & 업그레이드 노트
 
-- 상태: Living document (코어 1.3.x 추적)
+- 상태: Living document (코어 1.5.x 추적)
 
 `configVersion`는 `haechi.config.json`(및 `haechi.config.example.json`) 최상위에 찍히는 단일 정수입니다. 향후 호환성을 깨는 설정 스키마 변경이 구체적으로 게이트할 수 있는 **버전 앵커**로서, 다른 Haechi 빌드가 쓴 설정을 조용히 잘못 읽는 일을 막습니다.
 

package/docs/current/config-version.md

@@ -1,6 +1,6 @@
 # Haechi `configVersion` & Upgrade Notes
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 
 `configVersion` is a single integer stamped at the top of `haechi.config.json`
 (and `haechi.config.example.json`). It is a **versioned anchor** so a future
@@ -34,7 +34,7 @@ the "policies only get stronger / fail closed" invariant intact.
 
 | `configVersion` | Core line | Notes |
 |---|---|---|
-| `1` | 1.0 – 1.4.x | Initial stamp. All keys are additive over the 1.0 frozen config surface (`api-stability.md` §2.4). The 1.1.x additive keys (`logging`, `metrics`, the WS4-B `limits.maxInFlight` / `limits.shutdownGraceMs` / `limits.requestTimeoutMs` / `limits.headersTimeoutMs`, `configVersion` itself) and the 1.2.0 Reliability-Hardening keys (`filters.minConfidence` / `filters.allowlist`, `proxy.tls` / `proxy.trustForwardedProto`) all default to prior behavior. The 1.3.0 additions are new *values*, not new keys — `target.type` `anthropic`/`gemini`, additional detection types, and the `asia-pdpa`/`jp-appi` `privacy.profile` values. The 1.4.0 plugin-signing CLI (`plugin-keygen`/`plugin-sign`/`plugin-verify`) is **CLI surface, not config** — it adds no config keys. So the config schema (and `configVersion`) is unchanged. No migration needed. |
+| `1` | 1.0 – 1.4.x | Initial stamp. All keys are additive over the 1.0 frozen config surface (`api-stability.md` §2.4). The 1.1.x additive keys (`logging`, `metrics`, the WS4-B `limits.maxInFlight` / `limits.shutdownGraceMs` / `limits.requestTimeoutMs` / `limits.headersTimeoutMs`, `configVersion` itself) and the 1.2.0 Reliability-Hardening keys (`filters.minConfidence` / `filters.allowlist`, `proxy.tls` / `proxy.trustForwardedProto`) all default to prior behavior. The 1.3.0 additions are new *values*, not new keys — `target.type` `anthropic`/`gemini`, additional detection types, and the `asia-pdpa`/`jp-appi` `privacy.profile` values. The 1.4.0 plugin-signing CLI (`plugin-keygen`/`plugin-sign`/`plugin-verify`) is **CLI surface, not config** — it adds no config keys. The 1.5.0 store seams (`createAuditSink`/`createTokenVault` + the file-store defaults) are an **injected-provider** surface (wired via `createRuntime(config, providers)`), not config keys. So the config schema (and `configVersion`) is unchanged. No migration needed. |
 
 ## Upgrading
 

package/docs/current/configuration.ko.md

@@ -1,6 +1,6 @@
 # Haechi 설정 레퍼런스
 
-- 문서 상태: Living document(core 1.4.x 추적)
+- 문서 상태: Living document(core 1.5.x 추적)
 
 `haechi init`은 `haechi.config.json`을 생성하며, 비밀 정보를 포함하지 않는 템플릿은 `haechi.config.example.json`에 있습니다. 모든 커맨드는 `--config <path>`로 설정 파일을 읽습니다(기본값: `haechi.config.json`). 설정은 **fail-closed 방식으로 검증**됩니다. 알 수 없는 provider, 범위를 벗어난 숫자, 잘못된 형식의 값은 자동으로 무시되지 않고 로드 시점에 오류를 발생시킵니다. `haechi config`는 이 레퍼런스를 출력하며, `haechi status`는 특정 설정 파일의 *실제 적용* 상태를 출력합니다.
 

package/docs/current/configuration.md

@@ -1,6 +1,6 @@
 # Haechi Configuration Reference
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 
 `haechi init` writes `haechi.config.json`; a non-secret template is at `haechi.config.example.json`. Every command reads it with `--config <path>` (default `haechi.config.json`). Configuration is **validated fail-closed**: unknown providers, out-of-range numbers, and malformed values throw at load time rather than degrading silently. `haechi config` prints this reference; `haechi status` prints the *effective* state of a given config.
 

package/docs/current/operations-runbook.ko.md

@@ -1,6 +1,6 @@
 # Haechi 운영 런북 (Day-2)
 
-- 상태: Living document (코어 1.4.x 추적)
+- 상태: Living document (코어 1.5.x 추적)
 
 Haechi를 프로덕션에서 운영하기 위한 실무 가이드입니다: 배포, 환경변수 오버레이를 통한 설정, health/readiness/metrics 모니터링, 우아한 종료, 백프레셔 튜닝, 그리고 해시 체인을 깨지 않는 audit 로그 회전입니다.
 

package/docs/current/operations-runbook.md

@@ -1,6 +1,6 @@
 # Haechi Operations Runbook (Day-2)
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 
 A practical guide to running Haechi in production: deploy, configure via the
 env-var overlay, monitor with health/readiness/metrics, shut down gracefully,

package/docs/current/plugin-signing-and-trust.ko.md

@@ -1,6 +1,6 @@
 # 플러그인 서명 & 신뢰 앵커 큐레이션
 
-- 상태: Living document (코어 1.4.x 추적)
+- 상태: Living document (코어 1.5.x 추적)
 - 날짜: 2026-06-17
 
 Haechi의 기본은 **dependency injection**입니다 — `createRuntime(config, providers)`에

package/docs/current/plugin-signing-and-trust.md

@@ -1,6 +1,6 @@
 # Plugin Signing & Trust-Anchor Curation
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 - Date: 2026-06-17
 
 Haechi's default is **dependency injection** — you pass an `authProvider` to

package/docs/current/release-process.ko.md

@@ -1,6 +1,6 @@
 # Haechi Release Process
 
-- 문서 상태: Living document (core 1.4.x 추적)
+- 문서 상태: Living document (core 1.5.x 추적)
 - 작성일: 2026-06-10
 
 ## 1. 로컬 릴리즈 검증

package/docs/current/release-process.md

@@ -1,6 +1,6 @@
 # Haechi Release Process
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 - Date: 2026-06-10
 
 ## 1. Local Release Verification

package/docs/current/risk-register-release-gate.ko.md

@@ -1,8 +1,8 @@
 # Haechi 리스크 레지스터 및 릴리스 게이트
 
-- 문서 상태: Living document(core 1.4.x 추적)
+- 문서 상태: Living document(core 1.5.x 추적)
 - 작성일: 2026-06-16
-- 기준 버전: 1.4.x
+- 기준 버전: 1.5.x
 - 기준 브랜치: `main`
 
 ## 1. 현재 판단
@@ -14,9 +14,9 @@ Haechi는 `1.x` stable 라인을 출시했습니다. developer preview 게이트
 | 구분 | 판단 | 이유 |
 |---|---|---|
 | GitHub public | 허용 | 보안 한계, threat model, shared responsibility가 문서화됨 |
-| GitHub release/tag | 허용 (`v1.4.0` 릴리스됨) | `v1.4.0`이 현재 릴리스(additive minor — signed-plugin 저작 CLI); §5.7 / §5.8 항목은 모두 Resolved 유지, G9/G10/G11은 Pass |
-| npm stable | `haechi@1.4.0` publish됨 | `1.4.0`은 보안 교정된 `1.3.x` 기준 위에 `plugin-keygen`/`plugin-sign`/`plugin-verify` CLI를 더한 attested OIDC publish; config/API 파괴 없음(`configVersion`은 `1` 유지) |
-| production use | 운영자 게이트; `1.4.0`로 업그레이드 | 운영자 네트워크 통제, 인가/인증, key custody가 있을 때만 지원; 운영자는 민감한 제3자 업스트림 트래픽을 프록시로 라우팅하기 전에 최신 `haechi@1.4.0`(모든 `1.3.x` 보안 수정 + 플러그인 저작 CLI 포함)을 실행해야 함 |
+| GitHub release/tag | 허용 (`v1.5.0` 릴리스됨) | `v1.5.0`이 현재 릴리스(additive minor — 수평 확장을 위한 주입 가능한 audit/token-vault 저장소 시임); §5.7 / §5.8 항목은 모두 Resolved 유지, G9–G12는 Pass |
+| npm stable | `haechi@1.5.0` publish됨 | `1.5.0`은 `1.4.x` 기준 위에 `createAuditSink`/`createTokenVault` 저장소 시임(파일 기본값 바이트 동일)을 더한 attested OIDC publish; config/API 파괴 없음(`configVersion`은 `1` 유지) |
+| production use | 운영자 게이트; `1.5.0`로 업그레이드 | 운영자 네트워크 통제, 인가/인증, key custody가 있을 때만 지원; 여러 replica를 운영하는 운영자는 공유 저장소(`haechi-store-redis` 위성)를 주입해 audit 해시 체인과 token vault가 플릿 전체에서 유지되도록 해야 함 |
 
 ## 2. 릴리스 게이트
 
@@ -34,6 +34,7 @@ Haechi는 `1.x` stable 라인을 출시했습니다. developer preview 게이트
 | G9 | 2026-06-16 전체 코드리뷰 보완 게이트 (1.3.1로 발행) | `P0-CR-001` 및 `P1-CR-002`부터 `P1-CR-005`까지 해결 또는 책임자 명시 수용; P2 항목은 해결 또는 명시적 non-blocking 근거와 일정 기록; 연결된 등록부 갱신. **13개 `P*-CR-*` 항목이 모두 Resolved이며(§5.7) `haechi@1.3.1`(2026-06-16, attested OIDC publish)로 발행되었습니다; core가 1.3.0 → 1.3.1로 bump(patch, 보완 전용 — API/config 표면 변경 없음, `configVersion`은 `1` 유지)되었습니다.** | Pass (`haechi@1.3.1`, 2026-06-16) |
 | G10 | 2026-06-16 코드리뷰 round 2 (CR2) 보완 게이트 | CR2 등록부(`code-review-risk-register-2026-06-16-round2.md`, §5.8)는 **P0/P1을 발견하지 못했습니다**; 세 개의 P2(`CR2-001` 프록시 upstream-cancel, `CR2-002` token-vault audit hygiene, `CR2-003` plugin IPC reply 경계)와 P3 묶음(`CR2-004..008`)이 모두 **Resolved이며 `haechi@1.3.2`로 발행되었고**(`CR2-009` won't-fix, `CR2-010` accepted) 연결된 등록부가 갱신되었습니다. | Pass (`haechi@1.3.2`, 2026-06-16) |
 | G11 | 1.4.0 signed-plugin 저작 CLI | 1.0 Ed25519 trust gate를 위한 1차 저작 CLI — `plugin-keygen`(개인키 `0600`, 공개키 = trust anchor), `plugin-sign`(정확한 entry 바이트 바인딩), `plugin-verify`(런타임 동등 검증, fail-closed, `--allow-capability`); 개인키가 stdout/audit로 유출되지 않음; 적대적 검증 완료; `plugin-signing-and-trust.md` 큐레이션 런북이 P1-SEC-025 "운영자가 앵커를 큐레이션해야 함" 잔여를 해소. additive CLI 표면(config/API 파괴 없음, `configVersion`은 `1` 유지); `tests/api-contract.test.mjs` green; 코어는 zero runtime dependency 유지; 코어 1.3.3 → 1.4.0(additive minor)로 bump. | Pass (`haechi@1.4.0`, 2026-06-17) |
+| G12 | 1.5.0 수평 확장 저장소 시임 | audit sink와 token vault가 주입 가능한 **store**를 갖게 되어, 공유 저장소가 sha256 해시 체인 + token vault를 replica 전반에서 뒷받침할 수 있음(프로세스별 / 단일 writer 플릿 한계를 해소). `createAuditSink({store})` / `createTokenVault({store})` + 기본 `createFileAuditStore`/`createFileTokenStore`; 보안에 결정적인 chaining / `sanitizeAudit` / reveal governance / retention은 코어에 남고, store는 배타적 read-previous+persist(audit) / mutate+read(vault) 프리미티브만 추상화. 적대적 검증 완료: 파일 기본값 바이트 동일, chain 연산은 이전과 diff 동일, 비파일 store에서도 시임 동작, 동시 append/tokenize가 비분기·무손실 유지, CR2-002 audit-no-plaintext 유지. 새 export는 `api-stability.md` + `tests/api-contract.test.mjs`에 frozen; `createJsonlAuditSink`/`createLocalTokenVault`는 하위호환 래퍼; 코어는 zero runtime dependency 유지; 코어 1.4.0 → 1.5.0(additive minor)로 bump. `haechi-store-redis` 위성이 운영 소비자. | Pass (`haechi@1.5.0`, 2026-06-17) |
 
 ## 3. P0 배포 차단 리스크 상태
 

package/docs/current/risk-register-release-gate.md

@@ -1,6 +1,6 @@
 # Haechi Risk Register and Release Gates
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 - Date: 2026-06-16
 - Target version: 1.3.x
 - Branch: `main`
@@ -14,9 +14,9 @@ Haechi has shipped its `1.x` stable line. The developer-preview gate (G2, `haech
 | Category | Judgment | Rationale |
 |---|---|---|
 | GitHub public | Allowed | Security limitations, threat model, and shared responsibility are documented |
-| GitHub release/tag | Allowed (`v1.4.0` released) | `v1.4.0` is the current release (additive minor — the signed-plugin authoring CLI); all §5.7 / §5.8 findings remain Resolved and G9/G10/G11 are Pass |
-| npm stable | `haechi@1.4.0` published | `1.4.0` is an attested OIDC publish adding the `plugin-keygen`/`plugin-sign`/`plugin-verify` CLI over the security-remediated `1.3.x` baseline; no config/API break (`configVersion` stays `1`) |
-| Production use | Operator-gated; upgrade to `1.4.0` | Supported only with operator network controls, authz/authn, and key custody; operators should run the latest `haechi@1.4.0` (it carries every `1.3.x` security fix plus the plugin authoring CLI) before routing sensitive third-party upstream traffic through the proxy |
+| GitHub release/tag | Allowed (`v1.5.0` released) | `v1.5.0` is the current release (additive minor — injectable audit/token-vault store seams for horizontal scale); all §5.7 / §5.8 findings remain Resolved and G9–G12 are Pass |
+| npm stable | `haechi@1.5.0` published | `1.5.0` is an attested OIDC publish adding `createAuditSink`/`createTokenVault` store seams (file defaults byte-identical) over the `1.4.x` baseline; no config/API break (`configVersion` stays `1`) |
+| Production use | Operator-gated; upgrade to `1.5.0` | Supported only with operator network controls, authz/authn, and key custody; operators running multiple replicas should inject a shared store (the `haechi-store-redis` satellite) so the audit hash chain and token vault hold across the fleet |
 
 ## 2. Release Gates
 
@@ -34,6 +34,7 @@ Haechi has shipped its `1.x` stable line. The developer-preview gate (G2, `haech
 | G9 | 2026-06-16 full code-review remediation gate (shipped in 1.3.1) | `P0-CR-001` and `P1-CR-002` through `P1-CR-005` resolved or formally accepted; P2 items either resolved or scheduled with explicit non-blocking rationale; linked register updated. **All 13 `P*-CR-*` findings are Resolved (§5.7) and shipped in `haechi@1.3.1` (2026-06-16, attested OIDC publish); core bumped 1.3.0 → 1.3.1 (patch, remediation-only — no API/config surface change, `configVersion` stays `1`).** | Pass (`haechi@1.3.1`, 2026-06-16) |
 | G10 | 2026-06-16 code-review round 2 (CR2) remediation gate | The CR2 register (`code-review-risk-register-2026-06-16-round2.md`, §5.8) found **no P0/P1**; its three P2s (`CR2-001` proxy upstream-cancel, `CR2-002` token-vault audit hygiene, `CR2-003` plugin IPC reply bound) plus the P3 cluster (`CR2-004..008`) are all **Resolved and shipped in `haechi@1.3.2`** (`CR2-009` won't-fix, `CR2-010` accepted) and the linked register is updated. | Pass (`haechi@1.3.2`, 2026-06-16) |
 | G11 | 1.4.0 signed-plugin authoring CLI | First-party CLI for the 1.0 Ed25519 trust gate — `plugin-keygen` (private key `0600`, public key = trust anchor), `plugin-sign` (binds the exact entry bytes), `plugin-verify` (runtime-equivalent verification, fail-closed, `--allow-capability`); no private-key leak to stdout/audit; adversarially verified; the `plugin-signing-and-trust.md` curation runbook closes the P1-SEC-025 "operator must curate anchors" residual. Additive CLI surface (no config/API break, `configVersion` stays `1`); `tests/api-contract.test.mjs` green; core stays zero runtime dependency; core bumped 1.3.3 → 1.4.0 (additive minor). | Pass (`haechi@1.4.0`, 2026-06-17) |
+| G12 | 1.5.0 horizontal-scale store seams | The audit sink and token vault gain an injectable **store** so a shared store can back the sha256 hash chain + token vault across replicas (closes the per-process / single-writer fleet limitations). `createAuditSink({store})` / `createTokenVault({store})` + the default `createFileAuditStore`/`createFileTokenStore`; the security-critical chaining / `sanitizeAudit` / reveal governance / retention stay in core, the store only abstracts the exclusive read-previous+persist (audit) / mutate+read (vault) primitives. Adversarially verified: file defaults byte-identical, chain math diff-identical to prior, the seam works for a non-file store, concurrent appends/tokenize stay non-forked/lossless, CR2-002 audit-no-plaintext intact. New exports frozen in `api-stability.md` + `tests/api-contract.test.mjs`; `createJsonlAuditSink`/`createLocalTokenVault` are back-compat wrappers; core stays zero runtime dependency; core bumped 1.4.0 → 1.5.0 (additive minor). The `haechi-store-redis` satellite is the production consumer. | Pass (`haechi@1.5.0`, 2026-06-17) |
 
 ## 3. P0 Distribution-Blocking Risk Status
 

package/docs/current/shared-responsibility.ko.md

@@ -1,6 +1,6 @@
 # Haechi Shared Responsibility
 
-- 문서 상태: Living document (core 1.4.x 추적)
+- 문서 상태: Living document (core 1.5.x 추적)
 - 작성일: 2026-06-10
 
 ## 1. 책임 매트릭스

package/docs/current/shared-responsibility.md

@@ -1,6 +1,6 @@
 # Haechi Shared Responsibility
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 - Date: 2026-06-10
 
 ## 1. Responsibility Matrix

package/docs/current/threat-model.ko.md

@@ -1,6 +1,6 @@
 # Haechi Threat Model
 
-- 문서 상태: Living document(core 1.4.x 추적)
+- 문서 상태: Living document(core 1.5.x 추적)
 - 작성일: 2026-06-10
 
 ## 1. 보호 대상

package/docs/current/threat-model.md

@@ -1,6 +1,6 @@
 # Haechi Threat Model
 
-- Status: Living document (tracks core 1.4.x)
+- Status: Living document (tracks core 1.5.x)
 - Date: 2026-06-10
 
 ## 1. Assets Under Protection

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "haechi",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "description": "Self-hosted AI context enforcement across LLM, MCP, vLLM, Ollama, and agent traffic — a stable, zero-dependency security gateway.",
   "license": "Apache-2.0",
   "type": "module",

package/packages/audit/index.mjs

@@ -30,9 +30,73 @@ const FORBIDDEN_KEYS = new Set([
   "scopes", "labels"
 ]);
 
-export function createJsonlAuditSink({ path, anchor = null }) {
+// An audit STORE abstracts the exclusive "read-previous + persist" primitive so
+// the SAME core-owned sha256 hash chain can sit on top of a file today and a
+// shared store (e.g. Redis) in a future satellite. The contract is:
+//
+//   async transaction(fn) — runs `fn` inside an EXCLUSIVE critical section that
+//     serializes concurrent appends. `fn` receives { readLastIntegrity, persist }
+//     where readLastIntegrity() -> the last record's auditIntegrity (or null) and
+//     persist(record) durably appends the built record. transaction() returns
+//     fn's return value.
+//   async ready() — OPTIONAL health/writability probe returning { ok, reason? };
+//     the sink falls back to { ok: true } when the store omits it.
+//
+// The store deliberately knows NOTHING about anchoring, sanitization, or the
+// chain math — those stay core-owned in createAuditSink so a non-core store can
+// never fork or weaken the chain.
+
+// createFileAuditStore implements the store contract over the CURRENT JSONL
+// mechanism: a `${path}.lock` exclusive section wrapping mkdir + the critical
+// section, a tail-read for the previous integrity, and an appendFile persist.
+// The on-disk bytes are identical to the pre-seam sink.
+export function createFileAuditStore({ path }) {
   if (!path) {
-    throw new Error("JSONL audit sink requires path");
+    throw new Error("file audit store requires path");
+  }
+
+  return {
+    async transaction(fn) {
+      await mkdir(dirname(path), { recursive: true });
+      return withFileLock(`${path}.lock`, () => fn({
+        readLastIntegrity: () => readLastIntegrity(path),
+        persist: (record) => appendFile(path, `${JSON.stringify(record)}\n`, "utf8")
+      }));
+    },
+
+    // WS4-A readiness probe: a CHEAP writability check used by /__haechi/ready.
+    // A security gateway that cannot append to its audit log is NOT ready
+    // (fail-closed), so this confirms the audit directory exists and is writable
+    // WITHOUT writing an event (no audit-chain side effect). It returns the bare
+    // boolean and an enum reason — never a path value or any payload/PII.
+    async ready() {
+      try {
+        const dir = dirname(path);
+        await mkdir(dir, { recursive: true });
+        await access(dir, fsConstants.W_OK);
+        // If the audit file already exists, confirm it is writable too.
+        try {
+          await access(path, fsConstants.W_OK);
+        } catch (error) {
+          if (error.code !== "ENOENT") {
+            return { ok: false, reason: "audit_file_not_writable" };
+          }
+        }
+        return { ok: true };
+      } catch {
+        return { ok: false, reason: "audit_dir_not_writable" };
+      }
+    }
+  };
+}
+
+// createAuditSink holds the SECURITY-CRITICAL, core-owned logic: writeQueue
+// serialization, sanitizeAudit, the sha256 chain build, the anchor stream, and
+// the capabilities object. The store only supplies the exclusive
+// read-previous + persist primitive; anchor config never leaks into it.
+export function createAuditSink({ store, anchor = null }) {
+  if (!store || typeof store.transaction !== "function") {
+    throw new Error("audit sink requires a store with a transaction(fn) method");
   }
   const anchorMode = anchor?.mode ?? "none";
   const anchorPath = anchor?.path ?? null;
@@ -81,44 +145,41 @@ export function createJsonlAuditSink({ path, anchor = null }) {
       integrity: anchorMode === "none" ? "sha256-hash-chain" : "sha256-hash-chain+anchor"
     },
     async record(event) {
-      const write = writeQueue.then(async () => {
-        await mkdir(dirname(path), { recursive: true });
-        await withFileLock(`${path}.lock`, async () => {
-          const record = await buildIntegrityRecord(path, sanitizeAudit(event));
-          await appendFile(path, `${JSON.stringify(record)}\n`, "utf8");
-          await writeAnchor(record);
-        });
-      });
+      // The writeQueue serializes record() calls on this sink, and the store's
+      // transaction() adds the exclusive critical section; together they keep
+      // the chain strictly sequential and never forked under concurrency.
+      const write = writeQueue.then(() => store.transaction(async ({ readLastIntegrity, persist }) => {
+        const record = buildIntegrityRecord(await readLastIntegrity(), sanitizeAudit(event));
+        await persist(record);
+        await writeAnchor(record);
+        return record;
+      }));
       writeQueue = write.catch(() => {});
       await write;
     },
 
-    // WS4-A readiness probe: a CHEAP writability check used by /__haechi/ready.
-    // A security gateway that cannot append to its audit log is NOT ready
-    // (fail-closed), so this confirms the audit directory exists and is writable
-    // WITHOUT writing an event (no audit-chain side effect). It returns the bare
-    // boolean and an enum reason — never a path value or any payload/PII.
     async ready() {
-      try {
-        const dir = dirname(path);
-        await mkdir(dir, { recursive: true });
-        await access(dir, fsConstants.W_OK);
-        // If the audit file already exists, confirm it is writable too.
-        try {
-          await access(path, fsConstants.W_OK);
-        } catch (error) {
-          if (error.code !== "ENOENT") {
-            return { ok: false, reason: "audit_file_not_writable" };
-          }
-        }
-        return { ok: true };
-      } catch {
-        return { ok: false, reason: "audit_dir_not_writable" };
+      // Delegate to the store's writability probe; a store that omits it is
+      // treated as ready (the chain math has no readiness side effect of its own).
+      if (typeof store.ready === "function") {
+        return store.ready();
       }
+      return { ok: true };
     }
   };
 }
 
+// Thin back-compat wrapper: the original file-backed sink is now createAuditSink
+// over createFileAuditStore. Its returned shape (id, version, capabilities,
+// record, ready) and on-disk bytes are unchanged, so existing call sites
+// (runtime.mjs injection, tests) keep working untouched.
+export function createJsonlAuditSink({ path, anchor = null }) {
+  if (!path) {
+    throw new Error("JSONL audit sink requires path");
+  }
+  return createAuditSink({ store: createFileAuditStore({ path }), anchor });
+}
+
 export async function readAuditSummary(path) {
   const summary = {
     events: 0,
@@ -272,8 +333,13 @@ async function readAnchors(anchorPath) {
   return { bySequence, lastSequence };
 }
 
-async function buildIntegrityRecord(path, event) {
-  const previous = await readLastIntegrity(path);
+// PURE chain math: given the previous record's auditIntegrity (or null) and a
+// sanitized event, deterministically computes the next chained record. No fs,
+// no IO — the store supplies `previousIntegrity` (via its read-previous
+// primitive) so the SAME computation backs a file or a shared store. Exported
+// for store/satellite tests.
+export function buildIntegrityRecord(previousIntegrity, event) {
+  const previous = previousIntegrity ?? null;
   const sequence = previous ? previous.sequence + 1 : 1;
   const unsigned = {
     ...event,

package/packages/token-vault/index.mjs

@@ -11,8 +11,89 @@ const AUDIT_ID_DOMAIN = "haechi:token-vault:audit-id:v1";
 // this shape is treated as a misused raw value and never written verbatim.
 const VAULT_TOKEN_SHAPE = /^tok_[a-z0-9_]+_[a-f0-9]{16,}$/;
 
-export function createLocalTokenVault({
-  path,
+// A token STORE abstracts the token-record map + the exclusive mutation section
+// so the SAME core-owned tokenization can sit on a whole-file vault today and a
+// shared store (e.g. Redis) in a future satellite — the current whole-file
+// rewrite is not safe with multiple writers, so a shared store needs its own
+// exclusive critical section. The contract is:
+//
+//   async mutate(fn) — runs `fn` inside an EXCLUSIVE critical section that
+//     serializes concurrent mutations. `fn` receives a MUTABLE view
+//     { get(token), set(token, record), delete(token), entries() } over the
+//     token-record map, and the store persists the changes ATOMICALLY when `fn`
+//     resolves. mutate() returns `fn`'s return value. This is the
+//     multi-writer-safety primitive.
+//   async read(fn) — read-only access. `fn` receives { get(token), entries() }
+//     over a FRESH snapshot (no lock, matching how reveal/detokenize/export read
+//     today). read() returns `fn`'s value.
+//
+// The store deliberately knows NOTHING about crypto, reveal governance,
+// retention, or audit — those stay core-owned in createTokenVault so a non-core
+// store can never fork or weaken them. Prune-on-mutation is also core-owned: the
+// core deletes expired entries from the view before each operation, so the file
+// store persists the pruning on the trailing writeVault (no store cooperation
+// needed) and the in-memory store sees the same deletions.
+
+// createFileTokenStore implements the store contract over the CURRENT vault
+// mechanism: a `${path}.lock` exclusive section wrapping mkdir + readVault +
+// writeVault, with the view operating on vault.tokens in memory. The on-disk
+// vault JSON format (version/createdAt/tokens, 2-space, trailing newline,
+// temp+rename, 0600) stays byte-identical to the pre-seam vault.
+export function createFileTokenStore({ path }) {
+  if (!path) {
+    throw new Error("file token store requires path");
+  }
+
+  return {
+    async mutate(fn) {
+      await mkdir(dirname(path), { recursive: true });
+      return withFileLock(`${path}.lock`, async () => {
+        const vault = await readVault(path);
+        const result = await fn(mutableView(vault.tokens));
+        await writeVault(path, vault);
+        return result;
+      });
+    },
+
+    async read(fn) {
+      const vault = await readVault(path);
+      return fn(readView(vault.tokens));
+    }
+  };
+}
+
+// A mutable view over a token-record map (the file store backs this with
+// vault.tokens; the in-memory store with a Map). get/set/delete operate on the
+// live map so the store persists whatever the mutation left behind.
+function mutableView(tokens) {
+  return {
+    get: (token) => tokens[token],
+    set: (token, record) => {
+      tokens[token] = record;
+    },
+    delete: (token) => {
+      delete tokens[token];
+    },
+    entries: () => Object.entries(tokens)
+  };
+}
+
+function readView(tokens) {
+  return {
+    get: (token) => tokens[token],
+    entries: () => Object.entries(tokens)
+  };
+}
+
+// createTokenVault holds ALL the SECURITY-CRITICAL, core-owned logic:
+// mutationQueue serialization (cross-call), deterministic-vs-random token id
+// derivation, encrypt/decrypt, reveal governance (revealPolicy gate +
+// reasonCodes + safeAuditToken + recordVaultEvent), retention
+// (expiresAt/prune-on-mutation), detokenize, purge/purgeExpired,
+// exportMetadata, and capabilities. The store only supplies the exclusive
+// mutate/read primitive over the token-record map.
+export function createTokenVault({
+  store,
   cryptoProvider,
   revealPolicy = "disabled",
   retentionDays = 30,
@@ -20,8 +101,8 @@ export function createLocalTokenVault({
   deterministic = false,
   deterministicTypes = null
 }) {
-  if (!path) {
-    throw new Error("Local token vault requires path");
+  if (!store || typeof store.mutate !== "function" || typeof store.read !== "function") {
+    throw new Error("token vault requires a store with mutate(fn) and read(fn) methods");
   }
   if (!cryptoProvider) {
     throw new Error("Local token vault requires cryptoProvider");
@@ -37,16 +118,31 @@ export function createLocalTokenVault({
     return !deterministicTypes || deterministicTypes.includes(type);
   }
 
+  // The mutationQueue (cross-call serialization) stays in core, wrapping
+  // store.mutate. Together with the store's own exclusive critical section this
+  // keeps concurrent tokenize/purge from corrupting or losing tokens.
   let mutationQueue = Promise.resolve();
   async function enqueueMutation(operation) {
-    const mutation = mutationQueue.then(async () => {
-      await mkdir(dirname(path), { recursive: true });
-      return withFileLock(`${path}.lock`, operation);
-    });
+    const mutation = mutationQueue.then(() => store.mutate(operation));
     mutationQueue = mutation.catch(() => {});
     return mutation;
   }
 
+  // Prune expired entries from the mutable view before each operation. For the
+  // file store this deletes from the in-memory map so they are gone after the
+  // trailing writeVault; for any store the deletions are persisted by mutate().
+  // Returns the number pruned (purgeExpired counts on this).
+  function pruneExpiredView(view, now = Date.now()) {
+    let purged = 0;
+    for (const [token, record] of view.entries()) {
+      if (record.expiresAt && Date.parse(record.expiresAt) < now) {
+        view.delete(token);
+        purged += 1;
+      }
+    }
+    return purged;
+  }
+
   // The audit `token` field must never carry a raw secret. A legitimate token
   // id is a non-sensitive opaque `tok_<type>_<hexhash>` — recorded verbatim for
   // correlation. A caller who misuses the API and passes a raw value where a
@@ -122,14 +218,13 @@ export function createLocalTokenVault({
         })).slice(0, 32)}`
         : `tok_${type}_${shortHash(`${plaintext}:${randomBytes(16).toString("hex")}`)}`;
 
-      return enqueueMutation(async () => {
-        const vault = await readVault(path);
-        pruneExpiredTokens(vault);
+      return enqueueMutation(async (view) => {
+        pruneExpiredView(view);
 
-        const existing = vault.tokens[token];
+        const existing = view.get(token);
         if (existing) {
           existing.expiresAt = addDays(new Date(), retentionDays).toISOString();
-          await writeVault(path, vault);
+          view.set(token, existing);
           return { token, type, reused: true };
         }
 
@@ -140,15 +235,14 @@ export function createLocalTokenVault({
           type,
           context
         };
-        vault.tokens[token] = {
+        view.set(token, {
           type,
           createdAt: createdAt.toISOString(),
           expiresAt: addDays(createdAt, retentionDays).toISOString(),
           metadata: sanitizeMetadata(metadata),
           envelope: await cryptoProvider.encrypt({ plaintext, aad }),
           aad
-        };
-        await writeVault(path, vault);
+        });
         return { token, type };
       });
     },
@@ -166,8 +260,7 @@ export function createLocalTokenVault({
       // token); the message itself never interpolates the token argument.
       let reasonCode = "reveal_error";
       try {
-        const vault = await readVault(path);
-        const record = vault.tokens[token];
+        const record = await store.read((view) => view.get(token));
         if (!record) {
           reasonCode = "unknown_token";
           throw new Error("Unknown token");
@@ -210,12 +303,19 @@ export function createLocalTokenVault({
     // reachable through the proxy's explicit detokenizeResponses opt-in and is
     // limited to the caller-supplied token set. Audited by count, no plaintext.
     async detokenize({ tokens }) {
-      const vault = await readVault(path);
+      const records = await store.read((view) => {
+        const found = new Map();
+        for (const token of tokens) {
+          found.set(token, view.get(token));
+        }
+        return found;
+      });
+
       const values = new Map();
       let skipped = 0;
 
       for (const token of tokens) {
-        const record = vault.tokens[token];
+        const record = records.get(token);
         if (!record || (record.expiresAt && Date.parse(record.expiresAt) < Date.now())) {
           skipped += 1;
           continue;
@@ -237,36 +337,30 @@ export function createLocalTokenVault({
       return values;
     },
     async purge({ token }) {
-      return enqueueMutation(async () => {
-        const vault = await readVault(path);
-        pruneExpiredTokens(vault);
-        const existed = Boolean(vault.tokens[token]);
-        delete vault.tokens[token];
-        await writeVault(path, vault);
-        await recordVaultEvent({
-          operation: "token-vault:purge",
-          decision: "purge",
-          token
-        });
-        return { token, purged: existed, purgedAt: new Date().toISOString() };
+      const existed = await enqueueMutation(async (view) => {
+        pruneExpiredView(view);
+        const present = Boolean(view.get(token));
+        view.delete(token);
+        return present;
+      });
+      await recordVaultEvent({
+        operation: "token-vault:purge",
+        decision: "purge",
+        token
       });
+      return { token, purged: existed, purgedAt: new Date().toISOString() };
     },
     async purgeExpired() {
-      return enqueueMutation(async () => {
-        const vault = await readVault(path);
-        const purged = pruneExpiredTokens(vault);
-        await writeVault(path, vault);
-        await recordVaultEvent({
-          operation: "token-vault:purge-expired",
-          decision: "purge_expired",
-          count: purged
-        });
-        return { purged, purgedAt: new Date().toISOString() };
+      const purged = await enqueueMutation(async (view) => pruneExpiredView(view));
+      await recordVaultEvent({
+        operation: "token-vault:purge-expired",
+        decision: "purge_expired",
+        count: purged
       });
+      return { purged, purgedAt: new Date().toISOString() };
     },
     async exportMetadata({ type = null } = {}) {
-      const vault = await readVault(path);
-      return Object.entries(vault.tokens)
+      return store.read((view) => view.entries()
         .filter(([, record]) => !type || record.type === type)
         .map(([token, record]) => ({
           token,
@@ -274,11 +368,39 @@ export function createLocalTokenVault({
           createdAt: record.createdAt,
           expiresAt: record.expiresAt,
           metadata: sanitizeMetadata(record.metadata ?? {})
-        }));
+        })));
     }
   };
 }
 
+// Thin back-compat wrapper: the original file-backed vault is now
+// createTokenVault over createFileTokenStore. Its returned shape (id, version,
+// capabilities, tokenize, reveal, detokenize, purge, purgeExpired,
+// exportMetadata) and on-disk bytes are unchanged, so existing call sites
+// (runtime.mjs injection, tests) keep working untouched.
+export function createLocalTokenVault({
+  path,
+  cryptoProvider,
+  revealPolicy = "disabled",
+  retentionDays = 30,
+  auditSink = null,
+  deterministic = false,
+  deterministicTypes = null
+}) {
+  if (!path) {
+    throw new Error("Local token vault requires path");
+  }
+  return createTokenVault({
+    store: createFileTokenStore({ path }),
+    cryptoProvider,
+    revealPolicy,
+    retentionDays,
+    auditSink,
+    deterministic,
+    deterministicTypes
+  });
+}
+
 export async function readVault(path) {
   try {
     return JSON.parse(await readFile(path, "utf8"));
@@ -301,17 +423,6 @@ async function writeVault(path, vault) {
   await rename(tempPath, path);
 }
 
-function pruneExpiredTokens(vault, now = Date.now()) {
-  let purged = 0;
-  for (const [token, record] of Object.entries(vault.tokens)) {
-    if (record.expiresAt && Date.parse(record.expiresAt) < now) {
-      delete vault.tokens[token];
-      purged += 1;
-    }
-  }
-  return purged;
-}
-
 function sanitizeMetadata(metadata) {
   return Object.fromEntries(Object.entries(metadata).filter(([key]) => !["value", "plaintext", "payload"].includes(key)));
 }