@nullsquare/agent-authority 0.4.6 → 0.4.8

package/README.md

@@ -8,9 +8,9 @@
 
 **Agent Authority is a small execution layer that lets an agent use existing account permissions only for the task the user actually gave it.**
 
-[Task-first API](#task-first-api) · [Product proof gate](docs/product-proof.md) · [Task Leases](docs/task-leases.md) · [Durability](docs/durable-task-leases.md) · [Evidence](docs/evidence.md) · [Transport invariance](docs/transport-invariance.md) · [Roadmap](ROADMAP.md)
+[Quickstart](docs/quickstart.md) · [Connected GitHub](docs/connected-github.md) · [Task-first API](#task-first-api) · [Product proof gate](docs/product-proof.md) · [Task Leases](docs/task-leases.md) · [Durability](docs/durable-task-leases.md) · [Evidence](docs/evidence.md) · [Transport invariance](docs/transport-invariance.md) · [Roadmap](ROADMAP.md)
 
-> **Status: public pre-alpha / v0.4.5 Developer Preview on npm.** The `main` branch may contain unreleased work for the next preview. Agent Authority is not production-ready yet.
+> **Status: public pre-alpha / v0.4.7 Developer Preview on npm.** The task-first API is published as `@nullsquare/agent-authority/task`. Agent Authority is not production-ready yet.
 
 </div>
 
@@ -56,6 +56,99 @@ Requires Node.js 20+.
 npm install @nullsquare/agent-authority
 ```
 
+## Fresh-install quickstart
+
+You can see the task-authority model without a repository checkout, provider credential, OAuth setup, custom extractor, or Mission JSON.
+
+```bash
+mkdir agent-authority-quickstart
+cd agent-authority-quickstart
+npm init -y
+npm install @nullsquare/agent-authority
+curl -fsSL https://raw.githubusercontent.com/Null-Square/agent-authority/main/examples/quickstart.mjs -o quickstart.mjs
+node quickstart.mjs
+```
+
+Expected shape:
+
+```text
+ALLOW -> task discovered issue #42 and the exact comment effect ran
+STEP-UP -> The task established authority for 42 but this action requested 7.
+PASS -> useful task work ran; unrelated standing permission did not become task authority
+```
+
+The quickstart uses the real published `createTask()` API and reviewed GitHub authority extractor. Only the provider callback is a local provider-shaped fixture so the first run needs no account.
+
+The fresh-install path is continuously checked from blank Node 20 consumers against the public npm package. That proves the published package supports the documented task-first surface; it does **not** replace the still-open first-time-human under-10-minute adoption test.
+
+### Next: make one real GitHub call, still with no credential
+
+From the same blank project:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/Null-Square/agent-authority/main/examples/quickstart-github-live.mjs -o quickstart-github-live.mjs
+node quickstart-github-live.mjs
+```
+
+Expected shape:
+
+```text
+Standing GitHub permission -> repo.read
+Task authority -> Null-Square/agent-authority
+GitHub mode -> public API; no credential required
+ALLOW -> real GitHub returned Null-Square/agent-authority
+STEP-UP -> The task established authority for "Null-Square/agent-authority" but this action requested "octocat/Hello-World".
+PASS -> broader standing repo.read permission could not reach an unrelated repository for this task
+```
+
+This deliberately models the account/app capability as broader than the task. Mission-level `repo.read` can read repositories generally, while the Task authority root allows this task to reach only `Null-Square/agent-authority`. The first request makes one real public GitHub `fetch()`; the unrelated repository is stopped before a second network call.
+
+### Then: connect GitHub without putting the credential in task context
+
+v0.4.7 adds the connected-provider task path. Initialize the local runtime and pipe a GitHub credential on stdin:
+
+```bash
+npx agent-authority setup
+printf %s "$GITHUB_TOKEN" | npx agent-authority connect github --token-stdin
+```
+
+Then an application can use the same task-first surface with broker-owned provider execution:
+
+```js
+import { createRuntimeEnvironment } from '@nullsquare/agent-authority/runtime-env';
+import { createTask } from '@nullsquare/agent-authority/task';
+
+const env = createRuntimeEnvironment();
+
+const task = createTask({
+  principal: env.config.principal_id,
+  agent: 'agent:assistant',
+  request: 'Inspect only acme/private',
+  permissions: {
+    github: { allow: ['repo.read'], constraints: {} }
+  },
+  authority: {
+    repository: { kind: 'github.repository', value: 'acme/private' }
+  },
+  bindings: [
+    { service: 'github', action: 'repo.read', field: 'repository', authority: 'repository' }
+  ],
+  runtime: env.runtime
+});
+
+const result = await task.execute({
+  service: 'github',
+  action: 'repo.read',
+  context: { repository: 'acme/private' }
+});
+```
+
+`task.run(request, callback)` is for application-owned SDK/provider effects. `task.execute(request)` is for Agent Authority connected-provider execution, where credential resolution stays behind the broker boundary. Both use the same Task Lease semantics and the same deny/step-up error model.
+
+The connected GitHub CI proof packs the candidate into a fresh Node 20 consumer, creates a fresh Agent Authority home, pipes the repository's GitHub Actions installation token through stdin, confirms no plaintext token appears under the home, executes one authorized live GitHub request, and blocks an unrelated repository at the Task Lease. A fine-grained PAT or GitHub App token can use the same path for repositories that credential is allowed to access. Public CI does **not** claim independent access to an unrelated private repository.
+
+See [Fresh-install quickstart](docs/quickstart.md) and [Connected GitHub](docs/connected-github.md).
+
 ## Task-first API
 
 The preferred developer surface is intentionally small:
@@ -144,6 +237,8 @@ Example output:
 The task established authority for 42 but this action requested 7.
 ```
 
+For a connected provider, the same error/explanation flow applies to `task.execute(request)`. Successful connected execution also returns an ALLOW receipt and execution evidence, so reviewed provider outputs can feed `task.authorityFrom()` without copying the provider credential into the task.
+
 The task-first API is a facade over the existing Mission, Task Lease, execution-evidence and guard primitives. It does not weaken or replace them.
 
 ## Run the product demo
@@ -262,7 +357,7 @@ MCP gateway
 brokered provider execution
 ```
 
-A real Vercel AI SDK `ToolLoopAgent` integration also exercises the protected-tool boundary. See [Transport invariance](docs/transport-invariance.md).
+The task-first facade can now use both application-owned execution (`task.run`) and broker-owned connected execution (`task.execute`) without changing the underlying Task Lease. A real Vercel AI SDK `ToolLoopAgent` integration also exercises the protected-tool boundary. See [Transport invariance](docs/transport-invariance.md) and [Connected execution](docs/connected-execution-api.md).
 
 ## Durability
 
@@ -304,8 +399,14 @@ See [Durable Task Leases](docs/durable-task-leases.md).
 - authenticated durable Task Lease recovery;
 - stale-writer/CAS and mission-alias protection;
 - automatic durable Task Lease sessions;
+- task-first public facade and deterministic utility regression gate;
+- self-contained support/communications and operations/finance product proofs;
+- blank-project fixture quickstart against the public npm package;
+- blank-project real public GitHub onboarding with broader standing permission and narrower task authority;
+- encrypted connected-GitHub onboarding through `task.execute()` with the credential kept broker-internal;
+- safe sole-account default resolution while multiple connected accounts remain explicit/fail closed;
 - Node 20/22 CI, coverage, packed-consumer validation and CodeQL;
-- independent npm registry consumer verification.
+- independent npm registry consumer verification, including v0.4.7 connected execution.
 
 The lower-level evidence is documented under `docs/` and remains available for security review.
 
@@ -334,7 +435,9 @@ This is still a validation implementation.
 - Provider outputs are evidence-bound inside the trusted Agent Authority runtime but are not provider-signed remote attestations.
 - Source-data changes do not yet automatically invalidate already-derived authority.
 - Approved authority deltas are surfaced but not automatically applied into a live durable task.
-- GitHub token-stdin and the local encrypted vault are developer bridges, not final production OAuth/KMS UX.
+- Current Task Lease bindings are exact equality. The finance proof therefore steps up for a partial refund as well as an over-refund; a derived numeric ceiling remains an evidence-driven product question rather than a general policy language.
+- The local encrypted credential vault and stdin GitHub connection are trusted-host developer onboarding, not production OAuth/KMS credential lifecycle.
+- Public CI proves authenticated connected execution against the current repository but does not independently demonstrate access to an unrelated private repository.
 - Remote authenticated deployment and production approval UX remain incomplete.
 
 These are real limitations. They are not reasons to build every possible infrastructure layer before product adoption is proven.

package/ROADMAP.md

@@ -30,19 +30,38 @@ The engine has enough depth to test whether developers actually want this layer.
 - [x] task-first facade over Mission + Task Lease + Guard
 - [x] explicit service permissions without requiring hand-authored Mission JSON
 - [x] named task authority roots
-- [x] `task.run()` guarded effect boundary
-- [x] `task.authorityFrom()` strict evidence-derived authority
+- [x] `task.run()` guarded application-owned effect boundary
+- [x] `task.execute()` connected-provider effect boundary with broker-owned credential resolution
+- [x] `task.authorityFrom()` strict evidence-derived authority from `run()` or successful `execute()` output
 - [x] task-first binding of named authority to later effects
 - [x] human-readable authority-delta explanation
 - [x] same task-first calls can opt into durable local state by adding a store
 - [x] self-contained GitHub-shaped task-first demo
 - [x] deterministic utility regression benchmark
+- [x] first live provider proof through task-first API: GitHub issue discovery -> exact issue comment
+- [x] self-contained support/communications proof: Gmail thread -> exact Calendar attendee
+- [x] self-contained operations/finance proof: ticket -> order -> payment -> exact full refund
+- [x] automated blank-project quickstart against the current published npm package
+- [x] blank-project real-provider quickstart: broad standing `repo.read` -> one task-authorized public GitHub repository
+- [x] encrypted connected GitHub onboarding: stdin credential -> local vault/broker -> `task.execute()` -> live provider request
 - [ ] coding workflow: issue -> branch -> files -> PR, with merge/deploy outside authority
-- [ ] support/communications workflow: email -> customer -> meeting/CRM/reply target
-- [ ] operations/finance workflow: ticket -> order -> payment -> bounded refund
+- [ ] support/communications expansion: customer -> meeting + reply/CRM, or live task-first Google Actions proof
+- [ ] bounded finance refund: derived payment amount can authorize a smaller refund without authorizing an over-refund
 - [ ] first-time developer can complete a meaningful integration in under 10 minutes
 - [ ] at least one external developer adopts the package without project-author assistance
 
+The live GitHub task-first proof selected issue #9 through the reviewed provider mapping, established that issue through `task.authorityFrom()`, executed exactly one real comment mutation, blocked unrelated issue #1 with `authority_delta_required`, surfaced the established-vs-requested explanation, denied the same issue after task completion, and observed `reads=1` / `task_mutations=1` before cleanup.
+
+The support/communications proof uses the same task-first API across Gmail and Calendar: one authorized `thread_id` establishes one canonical `sender_email` through the reviewed Google extractor; only that attendee can be used for the task-bound Calendar event, while another thread or attendee executes zero provider-shaped callbacks. The example mirrors the real Google adapter contract but does not replace the still-open public Google Actions evidence gate.
+
+The operations/finance proof keeps one evidence-derived chain from support ticket -> order -> payment -> exact refund. The exact payment ID, amount in minor units, and currency are all bound before the refund callback can execute. Unrelated payment, over-refund, wrong currency, partial refund under the current equality model, and post-completion refund all execute zero additional refund callbacks. This proof exposed a deliberate product gap: current bindings are exact equality, so a legitimate partial refund also steps up. Do not add a general expression language; add a narrow derived numeric ceiling only when real workflow/adoption evidence shows partial refunds are required.
+
+The fixture fresh-install quickstart is independently exercised from blank Node 20 projects against the public npm package. The release-facing registry verifier for v0.4.7 installs that exact package, confirms the optional AI SDK is absent, and runs the ordinary public consumer contract plus the connected-execution consumer contract. This is automated compatibility evidence, not a substitute for the still-open first-time-human under-10-minute test.
+
+The live credential-free quickstart keeps Mission-level `github:repo.read` broader than the task, binds Task authority to `Null-Square/agent-authority`, performs one real public GitHub API call, and produces `authority_delta_required` for `octocat/Hello-World` before a second `fetch()` can run.
+
+v0.4.7 adds the authenticated connected path without creating an OAuth platform: a GitHub credential is accepted on stdin, stored in the encrypted trusted-local-host vault, resolved only inside the broker/provider runtime, and used by `task.execute()`. The live CI proof uses the repository's GitHub Actions installation token, confirms the raw token is not present in public task/connection state or plaintext under the Agent Authority home, executes the task-authorized repository read, and blocks the unrelated repository before connected provider execution. A fine-grained PAT or GitHub App token can use the same path for repositories it is allowed to access; public CI does not independently claim access to an unrelated private repository.
+
 Current utility regression metrics:
 
 ```text
@@ -143,6 +162,7 @@ Do **not** build a general semantic policy language around this primitive.
 - [x] same Task Lease through direct guard/SDK execution
 - [x] same Task Lease through MCP gateway
 - [x] same Task Lease through brokered provider execution
+- [x] task-first connected-provider execution through `task.execute()`
 - [x] real Vercel AI SDK protected-tool path
 - [x] interoperability/adversarial vectors across transports
 
@@ -152,8 +172,13 @@ Changing transport or configured harness execution path does not expand task aut
 
 Prioritize only the UX needed by successful P0 workflows.
 
+- [x] credential-free fresh-install quickstart validated against the current public npm package
+- [x] one low-friction real provider onboarding path: public GitHub read from a blank npm project
+- [x] authenticated connected-provider onboarding path: GitHub stdin credential + encrypted local vault + `task.execute()`
+- [x] safe sole-account default resolution; multiple connected accounts require explicit selection
+- [ ] independent private-repository onboarding proof with a credential that has private-repo access
+- [ ] production provider credential lifecycle / OAuth or GitHub App onboarding where real users require it
 - [ ] compact approval UI showing the exact authority delta
-- [ ] one low-friction real provider onboarding path
 - [ ] automatic short-lived agent session bootstrap where needed
 - [ ] framework integration starter focused on task-first API
 - [ ] external-developer quickstart feedback loop

package/docs/connected-execution-api.md

@@ -0,0 +1,60 @@
+# Task-owned vs broker-owned execution
+
+The task-first facade supports two effect ownership modes with the same Task Lease semantics.
+
+## Application-owned effect
+
+Use `task.run(request, callback)` when the application already owns the SDK or provider call:
+
+```js
+const result = await task.run(request, () => existingSdkCall());
+```
+
+The callback runs only after the Task Lease returns ALLOW. The task receives execution evidence for the exact callback output.
+
+## Agent Authority connected-provider effect
+
+Use `task.execute(request)` when the provider credential and provider adapter should stay behind Agent Authority's broker boundary:
+
+```js
+const result = await task.execute(request);
+```
+
+This requires the task to be created with an `ExecutingAuthorityRuntime`, such as the runtime produced by the local `createRuntimeEnvironment()` helper.
+
+The connected path performs:
+
+```text
+Task Lease evaluation
+      |
+      +--> DENY / STEP-UP -> stop before provider readiness or credential resolution
+      |
+      v
+connected-provider readiness
+      |
+      v
+credential broker resolves secret internally
+      |
+      v
+provider adapter executes
+      |
+      v
+sanitized output + ALLOW receipt + execution evidence
+```
+
+`task.execute()` converts broker runtime `deny` and `require_approval` results into the same `AuthorityDeniedError` and `AuthorityApprovalRequiredError` classes used by `task.run()`.
+
+Successful connected execution can therefore feed directly into `task.authorityFrom()` when a reviewed provider extractor exists.
+
+## Credential boundary
+
+The provider credential belongs to the broker/runtime, not the task request. It should not be copied into:
+
+- Mission or Task Lease authority facts;
+- model/tool arguments;
+- action receipts;
+- execution evidence;
+- provider-normalized output;
+- public connection listings.
+
+The local runtime's encrypted file vault is a developer/trusted-host reference implementation. Production applications should use an appropriate secret manager/KMS and provider-native credential lifecycle.

package/docs/connected-github.md

@@ -0,0 +1,140 @@
+# Connected GitHub quickstart
+
+This path is for a developer who has already understood the credential-free quickstart and now wants Agent Authority to execute through an authenticated GitHub connection.
+
+The product boundary is:
+
+```text
+GitHub token
+   |
+   v
+Agent Authority encrypted local vault
+   |
+   v
+CredentialBroker
+   |
+   v
+GitHub provider adapter
+   |
+   v
+task.execute(request)
+```
+
+The token is not placed in the task request, Mission, Task Lease, receipt, execution evidence, or public connection listing.
+
+## 1. Create a project
+
+```bash
+mkdir agent-authority-connected
+cd agent-authority-connected
+npm init -y
+npm install @nullsquare/agent-authority
+```
+
+Requires Node.js 20+.
+
+## 2. Initialize the local Agent Authority home
+
+```bash
+npx agent-authority setup
+```
+
+By default this creates `~/.agent-authority`. Provider secrets are stored in the local encrypted vault, whose files are restricted to the local user. This is a trusted-local-host developer reference backend, not a hostile-host or production KMS boundary.
+
+## 3. Connect GitHub without putting the token on the command line
+
+Use a GitHub token that has only the provider permissions your application actually needs.
+
+```bash
+printf %s "$GITHUB_TOKEN" | npx agent-authority connect github --token-stdin
+```
+
+The CLI verifies ordinary user/PAT credentials against GitHub before storing them. The token is accepted only on stdin and is written into the encrypted Agent Authority vault rather than task/model context.
+
+For CI installation tokens that do not support the `/user` verification endpoint, `--no-verify` is available for an already-trusted token source:
+
+```bash
+printf %s "$GITHUB_TOKEN" | npx agent-authority connect github --token-stdin --no-verify
+```
+
+Do not use `--no-verify` merely to bypass a failed or unknown credential.
+
+GitHub recommends fine-grained personal access tokens with minimum repository/permission scope for user-scoped access, and GitHub Apps for long-lived organization integrations. Agent Authority does not replace those provider-side controls; it adds a narrower task boundary on top of them.
+
+## 4. Run the connected task
+
+Copy `examples/quickstart-github-connected.mjs` into the project, or run the repository example from a checkout.
+
+The relevant application surface is intentionally small:
+
+```js
+import { createTask } from '@nullsquare/agent-authority/task';
+import { createRuntimeEnvironment } from '@nullsquare/agent-authority/runtime-env';
+
+const env = createRuntimeEnvironment();
+
+const task = createTask({
+  principal: env.config.principal_id,
+  agent: 'agent:assistant',
+  request: 'Inspect only acme/private',
+  permissions: {
+    github: {
+      allow: ['repo.read'],
+      constraints: {}
+    }
+  },
+  authority: {
+    repository: { kind: 'github.repository', value: 'acme/private' }
+  },
+  bindings: [
+    { service: 'github', action: 'repo.read', field: 'repository', authority: 'repository' }
+  ],
+  runtime: env.runtime
+});
+
+const result = await task.execute({
+  service: 'github',
+  action: 'repo.read',
+  context: { repository: 'acme/private' }
+});
+```
+
+Use `task.run(request, callback)` when your application owns the provider SDK call. Use `task.execute(request)` when Agent Authority's connected provider runtime should own credential resolution and provider execution.
+
+## Standing permission vs task authority
+
+The example deliberately leaves Mission-level `github:repo.read` broad while binding the Task Lease to one repository:
+
+```text
+connected GitHub account can read repositories
+            |
+            v
+Mission permits github:repo.read
+            |
+            v
+Task authority = acme/private
+            |
+            +--> acme/private -> ALLOW -> provider executes
+            |
+            +--> acme/other   -> STEP-UP -> provider does not execute
+```
+
+That is the product value: provider/IAM permission can remain broader than the exact task without becoming ambient agent authority.
+
+## Multiple GitHub accounts
+
+If there is exactly one active GitHub connection for the principal, requests that omit `account_id` resolve that sole connection. If multiple active GitHub accounts exist, Agent Authority does not guess: set `request.account_id` explicitly. Ambiguity fails closed.
+
+## Automated proof
+
+`.github/workflows/verify-connected-github.yml` installs the packed package into a blank Node 20 project, initializes a fresh Agent Authority home, connects the workflow's GitHub installation token through stdin, and runs the connected task against the live GitHub API.
+
+The gate also checks that:
+
+- the public connection listing does not contain `credential_ref` or the token;
+- the raw token does not appear in plaintext under `AGENT_AUTHORITY_HOME`;
+- an encrypted vault file is created;
+- the unrelated repository is stopped by the Task Lease before connected provider execution;
+- ordinary test/coverage/CodeQL/live-provider gates remain separate and must still pass.
+
+The automated workflow uses the repository's GitHub Actions installation token on the current repository. That proves the authenticated brokered execution path; it does **not** claim public CI access to an unrelated private repository. A user-supplied fine-grained PAT or GitHub App token can use the same path for repositories that credential is permitted to access.

package/docs/npm-release.md

@@ -4,7 +4,7 @@ The public package name is `@nullsquare/agent-authority`.
 
 Before any publication:
 
-1. the release commit must pass CI, CodeQL, live GitHub validation, current AI SDK integration validation, and packed-consumer validation;
+1. the release commit must pass CI, CodeQL, live GitHub validation, current AI SDK integration validation, task-first utility/demo gates, and packed-consumer validation;
 2. `npm pack` must contain the documented public exports;
 3. a fresh Node.js 20 consumer must install the tarball and run the current public behavior smoke test;
 4. the optional AI SDK integration must import without making `ai` a production dependency;
@@ -13,30 +13,50 @@ Before any publication:
 After publication, verify from a fresh project with:
 
 ```bash
-npm install @nullsquare/agent-authority@0.4.5
+npm install @nullsquare/agent-authority@0.4.7
 ```
 
-Then run the same consumer smoke flow through the registry-installed package. Registry verification is part of the release gate; a successful `npm publish` command alone is not sufficient.
+Then run the same consumer smoke flows through the registry-installed package. Registry verification is part of the release gate; a successful `npm publish` command alone is not sufficient.
 
-The repository includes `.github/workflows/verify-npm-registry.yml`, which verifies registry visibility, a clean Node.js 20 install, and the current public behavior from the registry artifact. For v0.4.5 the consumer exercises:
+The repository includes `.github/workflows/verify-npm-registry.yml`, which verifies registry visibility, a clean Node.js 20 install, and current public behavior from the registry artifact.
 
+For v0.4.7 the registry consumer exercises the existing v0.4.6 contract plus connected provider execution:
+
+- `createTask()` from `@nullsquare/agent-authority/task`;
+- explicit task permissions and named authority roots;
+- task-first allow / `authority_delta_required` behavior;
+- `task.explain()` for established-vs-requested authority deltas;
+- durable local-state opt-in through `JsonFileTaskLeaseStore` without changing normal task calls;
 - execution evidence and the reviewed Google/GitHub authority extractors;
 - `ExecutingAuthorityRuntime.executeTaskLease()` and `MissionMcpGateway` transport surfaces;
-- `JsonFileTaskLeaseStore` from `@nullsquare/agent-authority/storage`;
-- `DurableTaskLeaseSession` and `createDurableTaskLeaseSession()` from `@nullsquare/agent-authority/durable-task-lease`;
-- durable allow / `authority_delta_required` / completion behavior;
+- `JsonFileTaskLeaseStore`, `DurableTaskLeaseSession`, and the lower-level Task Lease APIs;
+- `task.execute(request)` for connected-provider execution;
+- the public `@nullsquare/agent-authority/runtime-env` export;
+- safe sole-account connection resolution while multiple active accounts remain ambiguous/fail closed;
+- connected execution where the credential is broker-internal, the task-authorized resource executes, and an unrelated resource is blocked before a second provider call;
 - the requirement that the optional `ai` package is not installed as a production dependency.
 
-This makes the registry artifact verification cover the same public durability, evidence and transport surfaces exercised by the repository tests rather than checking export names alone.
+This makes the registry artifact verification cover both application-owned task effects (`task.run`) and broker-owned connected provider effects (`task.execute`) together with the durability/evidence/transport surfaces they compose.
+
+The v0.4.7 independent registry verification passed after publication: npm visibility succeeded, a fresh Node.js 20 consumer installed the exact `@nullsquare/agent-authority@0.4.7` artifact, the optional AI SDK was absent, and both the ordinary package smoke and connected-execution smoke passed.
+
+The deterministic task utility fixture is also part of the source-release gate. It currently requires:
+
+```text
+normal task completion rate = 100%
+false approval rate = 0%
+true authority-delta step-up rate = 100%
+unauthorized effect rate = 0%
+```
 
-The v0.4.5 independent registry verification passed after publication: npm visibility succeeded and the fresh registry-installed consumer completed the durable Task Lease smoke.
+This fixture is a regression gate, not a real-world performance benchmark.
 
 ## npm vs GitHub release surfaces
 
 Publishing to the public npm registry does not automatically create either a GitHub Release or a GitHub Packages entry.
 
 - **npm registry** — `npm publish --access public` publishes `@nullsquare/agent-authority` to `registry.npmjs.org` / npmjs.com. This is the package users install with `npm install`.
-- **GitHub Releases** — a separate GitHub object, normally backed by a Git tag such as `v0.4.5`. A release must be created explicitly or by release automation.
+- **GitHub Releases** — a separate GitHub object, normally backed by a Git tag such as `v0.4.7`. A release must be created explicitly or by release automation.
 - **GitHub Packages** — a separate package registry. It only appears when the package is published to GitHub's npm registry (`npm.pkg.github.com`); publishing to npmjs.com does not populate it.
 
 Agent Authority currently uses npmjs.com as its public package registry. Therefore an empty GitHub **Packages** section is expected unless the project intentionally adopts dual publication. A GitHub **Release** is still useful for source-release discoverability and should track published versions, but it is independent from npm publication.