feat(authority): add Stage 2A NoKV AuthorityStore candidate

docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md

@@ -3,15 +3,15 @@
 - Status: Draft, under maintainer review
 - Initially proposed by: NoKV Lab
 - Widened by: LoopX maintainers
-- Date: 2026-08-05; revised 2026-09-01
+- Date: 2026-08-05; revised 2026-09-02
 - Scope: one provider-neutral LoopX authority contract with built-in file,
   optional NoKV, and optional PostgreSQL provider profiles, complementing
   [`host-integration-surface-v0`](../../reference/protocols/host-integration-surface-v0.md)
 - Source baseline: LoopX `a0c20f1779d273e7aaa4bd3ea166d145d466e6d5`
-- Provider API baseline: NoKV `3d75d96965` (0.11.0 line). The Python
-  `publish_bytes` generation-CAS mapping was exercised once by hand against a
-  live NoKV stack at that pin (see the example README); the run is evidence for
-  the mapping only, not part of any merge gate
+- Provider API baseline: NoKV `7bb3ffd6512fd57d9c0f193aa6d9c5b935d77f30`
+  (release 0.11.0, Python API 1, Holt pinned to 0.8.6). The Stage 2A executable
+  qualification admits only that SDK contract and this checkout's helper. It
+  remains candidate evidence, not a merge gate or authority promotion
 - PostgreSQL baseline: the TypeScript Stage 2B candidate implements the store
   contract and has passed a real PostgreSQL 16 transaction matrix. No shared
   authority service, runtime caller, authentication boundary, or authority
@@ -1428,6 +1428,30 @@ claim that the complete P0 acceptance gate above passes. Historical latency or
 fault results are informative only; they are not a durability, recovery, HA,
 or production qualification claim.
 
+The additional TEST ONLY Stage 2A probe in
+`examples/nokv-authority-store/` opens three independent SDK helper processes
+and checks fresh create, exact generation update, reconciliation after an
+applied CAS response is deliberately lost, a one-winner/two-contender CAS,
+winner/loser receipt behavior, and fresh-process receipt/history readback. Its
+executable fixes argv to one absolute Python executable, the interpreter
+isolation flag `-I`, and this checkout's reviewed helper, so `PYTHONPATH`
+cannot substitute the `nokv` module; the helper fails closed unless the SDK
+reports NoKV 0.11.0 and Python API 1, and the report repeats those two
+admission constants rather than server-observed values. It validates read metadata against the current workbench
+incarnation and validates publish responses against the requested workbench,
+path, operation, revision, and generation. The AuthorityStore accepts even a
+successful publish response only after a fresh read proves the exact persisted
+transaction under the current workbench incarnation. This closes false success
+at the LoopX boundary, but NoKV's current Python API does not atomically bind an
+expected workspace incarnation into `publish_bytes`; preventing a write after a
+concurrent remove/recreate remains an explicit provider-contract hold.
+Only a successful live JSON report is evidence for that single-node Stage 2A
+store-conformance run; deterministic tests are sequence tests only. This
+LoopX-only candidate changes neither NoKV source nor its workbench/artifact data
+model, and it does not prove runtime shadow parity, a multi-Agent canary,
+authority-source promotion, HA, restart recovery, capacity, or production
+routing.
+
 ## Appendix B: Handoff-Mode Decision Record (2026-08-10)
 
 This appendix writes down a direction already agreed during the PR #2787

docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md

@@ -3,14 +3,15 @@
 - 状态：Draft，正在接受 maintainer review
 - 最初提案方：NoKV Lab
 - 扩展修订方：LoopX maintainer
-- 日期：2026-08-05；修订于 2026-09-01
+- 日期：2026-08-05；修订于 2026-09-02
 - 范围：一个 provider-neutral 的 LoopX 权威合同，支持内置 file、可选 NoKV
   与可选 PostgreSQL provider profile，用来补充
   [`host-integration-surface-v0`](../../reference/protocols/host-integration-surface-v0.md)
 - 源码基线：LoopX `a0c20f1779d273e7aaa4bd3ea166d145d466e6d5`
-- Provider API 基线：NoKV `3d75d96965`（0.11.0 线）。Python `publish_bytes`
-  generation-CAS 映射已在该基线的真实 NoKV stack 上手工跑过一次（见示例 README）；
-  该次运行只是映射本身的证据，不属于任何合并门槛
+- Provider API 基线：NoKV `7bb3ffd6512fd57d9c0f193aa6d9c5b935d77f30`
+  （release 0.11.0、Python API 1、Holt 固定为 0.8.6）。Stage 2A 的可执行资格
+  验证只接受这份 SDK 合同与本 checkout 的 helper；它仍是候选证据，不是合并门槛
+  或 authority promotion
 - PostgreSQL 基线：TypeScript Stage 2B candidate 已实现 store contract，且已通过
   真实 PostgreSQL 16 transaction matrix；shared authority service、runtime caller、
   authentication boundary 与 authority promotion 均尚未交付
@@ -1145,6 +1146,24 @@ migration/promotion、service recovery 或 HA。
 验收门通过。历史 latency 或 fault 结果只具有参考意义，不构成 durability、recovery、
 HA 或 production qualification 声明。
 
+`examples/nokv-authority-store/` 还包含一个 TEST ONLY 的 Stage 2A probe：它会
+打开三个相互独立的 SDK helper 进程，验证 fresh create、精确 generation update、
+一次 CAS 已落盘但响应被刻意丢弃后的回读 reconciliation、两个竞争者恰一胜出的
+CAS、胜负双方的 receipt 行为，以及新进程对 receipt 与完整 history 的回读。该可
+执行入口把 argv 固定为一个绝对 Python executable、解释器隔离标志 `-I`，加本
+checkout 中经过评审的 helper，因此 `PYTHONPATH` 无法替换 `nokv` 模块；helper 只
+接受 NoKV 0.11.0 / Python API 1，report 中重复的是这两个准入常量，而非从服务端读
+回的值。它把 read metadata 与当前
+workbench incarnation 对照，并针对请求的 workbench、path、operation、revision、
+generation 校验 publish 回包。即使 publish 回包报告成功，AuthorityStore 也必须
+重新读取并证明当前 workbench incarnation 下持久化了完全相同的 transaction，才会
+接受成功。这在 LoopX 边界消除了错误成功，但 NoKV 当前 Python API 尚不能把
+expected workspace incarnation 原子绑定到 `publish_bytes`；阻止 concurrent
+remove/recreate 后的写入仍是明确的 provider-contract hold。只有成功的 live JSON report 才是该次单节点 Stage 2A store-conformance
+运行的证据；确定性测试只证明场景序列。这个纯 LoopX 候选既不修改 NoKV 源码，也
+不改变其 workbench/artifact 数据模型；它不证明 runtime shadow parity、multi-Agent
+canary、authority-source promotion、HA、重启恢复、容量或生产路由。
+
 ## 附录 B：交接模式决策记录（2026-08-10）
 
 本附录把 PR #2787 评审中已同意的方向落成文字，作为实施前置条件的一部分。

examples/nokv-authority-store/README.md

@@ -0,0 +1,134 @@
+# Stage 2A NoKV AuthorityStore candidate qualification (TEST ONLY)
+
+This directory contains an explicit, write-producing single-node conformance
+probe for the Stage 2A `NoKVAuthorityStore` candidate. It is **TEST ONLY**.
+LoopX does not select NoKV by importing this code, and a successful run does
+not connect a runtime shadow, run a multi-Agent canary, or flip an authority
+source.
+
+The integration priority remains:
+
+1. the native, full NoKV CLI as the primary operator and production surface;
+2. the NoKV Python SDK as the secondary programmable surface; and
+3. optional sidecars only as adapters around those surfaces, never as the main
+   authority API.
+
+This probe intentionally exercises the current Python SDK bridge because it is
+the available raw byte-CAS seam. It always starts this checkout's reviewed
+`NoKVJsonLinesTransport` and `nokv_jsonl_helper.py`; it has no fake, skip, or
+"unverified but successful" CLI path. The helper admits exactly NoKV SDK
+`0.11.0` / Python API `1`, and the successful report repeats both values.
+
+## What it proves
+
+Against one **already existing** NoKV workbench, the probe starts three
+independent helper processes and verifies:
+
+- the selected tenant/goal path is initially absent and can be created;
+- the stored path generation advances from 1 to 2 under exact generation CAS;
+- after the generation-2 CAS lands, an injected response loss is reconciled
+  from the durable authority envelope and operation receipt rather than from
+  the lower-layer response;
+- every successful CAS response is accepted only after a fresh read proves the
+  exact transaction in the current workbench incarnation;
+- two writes released together against generation 2 produce exactly one
+  generation-3 winner and one typed conflict;
+- the losing operation does not acquire a durable receipt; and
+- a third, freshly opened transport reads the winning envelope, its complete
+  three-entry history, the response-lost operation receipt, and the retained
+  winner receipt.
+
+If the SDK, helper, workbench, backend, CAS, or independent readback cannot be
+proved, the process exits nonzero. The normal test suite uses deterministic
+fakes only to test this sequence and does **not** count as live evidence.
+
+The probe does not prove an atomic expected-incarnation publication fence,
+runtime shadow parity, a multi-Agent canary, authority promotion, HA, failover,
+restart recovery, capacity, or performance. NoKV generation can restart after
+workbench recreation, so the current adapter fails closed through authoritative
+post-write readback; preventing the stale-incarnation write itself requires a
+future provider primitive. The probe also does not create a workbench. A green
+run is Stage 2A single-node storage conformance evidence only.
+
+## Inputs
+
+Use a current NoKV Python environment. Keep the client configuration in an
+ignored local file; do not commit credentials. Static routing is valid for a
+single-node NoKV deployment—etcd is not required by this probe. The following
+shape is illustrative:
+
+```json
+{
+  "root_id": "00000000000000000000000000000000",
+  "routing": {
+    "kind": "static",
+    "endpoint": "127.0.0.1:7412",
+    "logical_shard_id": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
+    "object_namespace_id": "cccccccccccccccccccccccccccccccc",
+    "placement_generation": 1,
+    "owner_epoch": 1
+  },
+  "object_store": {
+    "kind": "s3",
+    "bucket": "qualification-bucket",
+    "region": "us-east-1",
+    "root": "/loopx-qualification",
+    "endpoint": "http://127.0.0.1:9000",
+    "access_key_id": "set-in-your-ignored-local-file",
+    "secret_access_key": "set-in-your-ignored-local-file",
+    "virtual_host_style": false,
+    "skip_signature": false
+  }
+}
+```
+
+Configuration objects are exact-key contracts. An unknown top-level, routing,
+or object-store key fails before an SDK routing config, object-store config, or
+client is constructed. In particular, a misspelled explicit credential cannot
+silently fall through to NoKV's ambient provider chain. Intentionally omitted
+optional S3 credential fields retain the NoKV SDK's normal behavior.
+
+Pass only the absolute path to the Python executable that resolves the qualified
+NoKV SDK. The probe itself fixes the remaining argv to the interpreter isolation
+flag `-I` followed by the reviewed helper in this checkout; callers cannot
+supply a wrapper argument or an alternate helper path, and `PYTHONPATH`,
+`PYTHONHOME`, or user site-packages cannot redirect the `nokv` import away from
+that executable's own environment:
+
+```text
+/path/to/nokv-python-environment/bin/python
+```
+
+Choose a fresh tenant/goal pair for every run. The probe refuses to overwrite
+an existing authority envelope and deliberately leaves its three-generation
+test envelope behind for inspection. Use a disposable qualification namespace
+or remove it later with the native NoKV CLI according to that environment's
+retention policy.
+
+## Run
+
+From the LoopX repository root:
+
+```bash
+node --no-warnings --experimental-strip-types \
+  examples/nokv-authority-store/live-qualification.ts \
+  --execute-live \
+  --config-json /path/to/ignored/nokv-client.json \
+  --python-executable /path/to/nokv-python-environment/bin/python \
+  --tenant-id qualification-tenant-20260902 \
+  --goal-id qualification-goal-20260902-01 \
+  --workbench existing-qualification-workbench
+```
+
+`--execute-live` is mandatory and is checked before any helper starts. Exit 0
+means every listed live check passed. Any unavailable, failed, ambiguous,
+unfenced, pre-existing, or unreadable state exits nonzero with a compact JSON
+reason; provider stderr, endpoints, credentials, and raw SDK errors are not
+copied into that result. A successful JSON report includes
+`"qualification_scope":"stage_2a_single_node_store_conformance"`,
+`"nokv_sdk_version":"0.11.0"`, and `"nokv_api_version":1`. The two version
+fields are the helper's admission constants: the helper refuses to open a client
+for any other SDK version or API version, so a successful report implies them,
+but they are not values read back from the NoKV server. The report is Stage
+2A/helper-admission evidence only, not runtime-shadow, canary, HA, or
+production-readiness evidence.