@nullsquare/agent-authority 0.4.6 → 0.4.7

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) · [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.6 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,57 @@ 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.
+
+An automated blank-project gate independently installed `@nullsquare/agent-authority@0.4.6` from npm on Node 20 and ran this exact file successfully. That proves the current published package supports the documented path; 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.
+
+A separate blank-project CI gate has passed this exact live path against npm `0.4.6`. Authenticated/private-repository onboarding remains separate follow-on work.
+
+See [Fresh-install quickstart](docs/quickstart.md).
+
 ## Task-first API
 
 The preferred developer surface is intentionally small:
@@ -304,6 +355,10 @@ 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 current npm package;
+- blank-project real public GitHub onboarding with broader standing permission and narrower task authority;
 - Node 20/22 CI, coverage, packed-consumer validation and CodeQL;
 - independent npm registry consumer verification.
 
@@ -334,7 +389,8 @@ 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.
+- Public GitHub onboarding is credential-free for read-only public repositories; authenticated/private-repository onboarding and production OAuth/KMS UX remain incomplete.
 - 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

@@ -37,12 +37,27 @@ The engine has enough depth to test whether developers actually want this layer.
 - [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
 - [ ] 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 a blank Node 20 project against the latest public npm package. The passing proof installed `@nullsquare/agent-authority@0.4.6`, did not install the optional AI SDK, allowed the exact issue #42 effect, stepped up unrelated issue #7, and observed no unrelated callback. This is automated compatibility evidence, not a substitute for the still-open first-time-human under-10-minute test.
+
+The live fresh-install quickstart goes one step further from another blank Node 20 project: Mission-level `github:repo.read` remains broader than the task, Task authority binds that action to `Null-Square/agent-authority`, one real public GitHub API call succeeds, and `octocat/Hello-World` produces `authority_delta_required` before a second `fetch()` can run. No credential is required for the default public-repository path. Authenticated/private-repository onboarding remains separate follow-on work.
+
 Current utility regression metrics:
 
 ```text
@@ -152,8 +167,10 @@ 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
+- [ ] authenticated/private-provider onboarding path
 - [ ] 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,46 @@ 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.6
 ```
 
 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.
 
-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.6 the consumer exercises:
+
+- `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;
 - 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 the product-facing task-first API and the lower-level durability/evidence/transport surfaces it composes, rather than checking export names alone.
+
+The v0.4.6 independent registry verification passed after publication: npm visibility succeeded and the fresh Node.js 20 registry-installed consumer executed the current task-first + durable behavior smoke successfully.
+
+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.6`. 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.

package/docs/product-proof.md

@@ -71,13 +71,137 @@ Do not prioritize another deep authorization subsystem until the following are d
 
 - [ ] a new developer can run a meaningful task-first example in under 10 minutes;
 - [ ] at least three real workflow examples exist: coding, support/communications, and operations/finance;
-- [ ] the same task-first API works in-memory and with durable local state;
-- [ ] useful-task completion stays high under the product benchmark;
-- [ ] normal task actions do not trigger unnecessary approvals;
-- [ ] unrelated-resource effects execute zero provider callbacks;
-- [ ] approval/step-up output explains the established authority and requested delta clearly;
+- [x] the same task-first API works in-memory and with durable local state;
+- [x] useful-task completion stays high under the deterministic product benchmark;
+- [x] normal fixture task actions do not trigger unnecessary approvals;
+- [x] unrelated-resource effects execute zero provider callbacks in the deterministic fixture, live GitHub proof, support/communications proof, and operations/finance proof;
+- [x] approval/step-up output explains the established authority and requested delta clearly;
 - [ ] at least one external developer uses the package without project-author assistance.
 
+The checked utility items are evidence about the current deterministic fixtures and live GitHub proof, not a claim that arbitrary real-world agent workloads have already met the same rates.
+
+## First live provider product proof
+
+The existing GitHub Actions mutation validation now runs through the public task-first API rather than hand-assembling Mission + Task Lease + Guard.
+
+The live workflow uses:
+
+```text
+createTask()
+   |
+   v
+task.run(issue.list)
+   |
+   v
+task.authorityFrom(reviewed GitHub output)
+   |
+   v
+issue #9 becomes downstream task authority
+   |
+   +--> task.run(issue.comment #9) -> real GitHub mutation
+   +--> task.run(issue.comment #1) -> STEP-UP, zero provider mutation
+   |
+   v
+task.complete()
+   |
+   v
+issue.comment #9 -> DENY, zero provider mutation
+```
+
+Passing CI evidence from the live run:
+
+- repository root: `Null-Square/agent-authority`;
+- reviewed fixture selection: issue `#9`;
+- `task.authorityFrom()` established issue `#9` as downstream authority;
+- exactly one real GitHub comment mutation executed;
+- unrelated issue `#1` produced `authority_delta_required` before provider mutation;
+- `task.explain()` reported established authority `9` vs requested value `1`;
+- the same issue was denied after `task.complete()`;
+- provider calls before cleanup: `reads=1`, `task_mutations=1`;
+- the temporary validation comment was deleted outside the authority proof.
+
+This establishes a real-provider product proof for the facade, but it is **not yet** the full coding-agent product workflow. Branch creation, file edits and PR creation still need to be chained under task-derived authority while merge/deploy remain outside the task.
+
+## Cross-provider support/communications proof
+
+`examples/task-first-support.js` exercises the same public facade across two service boundaries using the exact field names and normalized sender shape used by the Google adapter:
+
+```text
+Task: handle one customer email and schedule the requested meeting
+
+origin thread authority
+      |
+      v
+task.run(gmail:thread.read)
+      |
+      v
+reviewed Gmail sender extractor
+      |
+      v
+customer@example.com
+      |
+      v
+task.bind(calendar:event.create.attendee_email)
+      |
+      +--> exact customer meeting -> ALLOW
+      +--> unrelated attendee -> STEP-UP, zero Calendar callbacks
+      |
+      v
+task.complete() -> same meeting authority no longer usable
+```
+
+The task also binds the Gmail `thread_id` and Calendar `calendar_id` to explicit task-entry roots. A different Gmail thread is stopped before its callback runs.
+
+The example and `test/task-product-support.test.js` run on Node 20 and Node 22 CI. The support proof demonstrates that the task-first model crosses Gmail -> Calendar without a second authorization abstraction.
+
+This is intentionally a **self-contained product proof**. It mirrors the real Google provider contract but does not close the separate public Google Actions evidence gate; that gate still requires repository OAuth secrets.
+
+## Operations / finance lineage proof
+
+`examples/task-first-finance.js` exercises a longer evidence-derived authority chain without adding another provider, policy DSL, or numeric relation language:
+
+```text
+Task: resolve one support ticket by refunding only its payment
+
+ticket:481
+   |
+   v
+task.run(helpdesk:ticket.read)
+   |
+   v
+order:991
+   |
+   v
+task.run(orders:order.read)
+   |
+   v
+payment:abc123
+   |
+   v
+task.run(payments:payment.read)
+   |
+   +--> amount = 12500 minor units
+   +--> currency = USD
+   |
+   v
+task.bind(refund payment_id + amount + currency)
+   |
+   +--> exact full refund -> ALLOW
+   +--> another payment -> STEP-UP, zero refund callbacks
+   +--> over-refund -> STEP-UP, zero refund callbacks
+   +--> wrong currency -> STEP-UP, zero refund callbacks
+   +--> partial refund -> STEP-UP under current exact binding model
+   |
+   v
+task.complete() -> same refund authority no longer usable
+```
+
+The task cannot read an arbitrary order before the ticket establishes the order fact: the unresolved binding fails closed before the order callback runs. The same pattern continues through payment and refund.
+
+The example and `test/task-product-finance.test.js` run on Node 20 and Node 22 CI. On the passing fixture, provider-shaped callbacks are exactly one ticket read, one order read, one payment read and one refund.
+
+This proof intentionally exposes a **product limitation rather than hiding it behind new policy machinery**: Task Lease bindings currently require exact equality. Therefore the payment amount `12500` can authorize an exact `12500` refund, but a legitimate partial refund such as `5000` also produces `authority_delta_required`. A future narrow `requested amount <= evidence-derived payment amount` relation may be justified if real provider/adoption evidence shows partial refunds are needed. Until then, the repository should keep this limitation visible instead of adding a general expression language speculatively.
+
 ## Utility metrics
 
 Security tests remain required, but product work should additionally track:
@@ -102,7 +226,7 @@ true authority-delta step-up rate = 100%
 unauthorized effect rate = 0%
 ```
 
-Real provider/harness benchmarks should replace or supplement the fixture as the product matures.
+The current fixture run contains 40 normal tasks and 10 unrelated-resource attempts. Real provider/harness benchmarks should replace or supplement it as the product matures.
 
 ## Three product proofs
 
@@ -120,6 +244,8 @@ repository -> issue -> task branch -> changed files -> pull request
 
 Unrelated repositories, issues, merge and deploy remain outside the task.
 
+The live issue-discovery -> exact-issue-comment proof is the first slice of this direction; it does not complete the branch/files/PR lineage yet.
+
 ### Support / communications agent
 
 Task:
@@ -132,7 +258,7 @@ Desired authority lineage:
 email thread -> customer -> meeting / CRM record / reply target
 ```
 
-The underlying connected account may have broad access; task authority follows only the customer/resource discovered through the authorized thread.
+The self-contained Gmail-thread -> exact Calendar-attendee slice is now established. The next value proof should connect the same customer authority to another useful downstream action (for example reply/CRM) or rerun the task-first flow with the real Google Actions fixture once repository OAuth secrets are available.
 
 ### Operations / finance agent
 
@@ -146,7 +272,7 @@ Desired authority lineage:
 ticket -> customer -> order -> payment -> refund <= original payment
 ```
 
-This is the strongest long-term proof because it combines resource lineage with an amount ceiling.
+The self-contained ticket -> order -> payment -> **exact full refund** lineage is now established. The remaining product question is narrower than the original workflow: whether partial refunds are important enough to justify one evidence-derived numeric ceiling relation. Current exact bindings intentionally step up for a smaller amount rather than guessing that relation into the core.
 
 ## Freeze list