@nullsquare/agent-authority 0.4.1 → 0.4.3

package/README.md

@@ -8,9 +8,9 @@
 
 **Agent Authority turns a human-approved task into temporary execution authority, then keeps that authority bounded as the agent discovers resources, crosses tools, and performs side effects.**
 
-[Task Leases](docs/task-leases.md) · [Validate](docs/validation.md) · [Integration contract](docs/integration-contract.md) · [CLI](docs/cli.md) · [Architecture](docs/architecture.md) · [Roadmap](ROADMAP.md) · [Contributing](CONTRIBUTING.md)
+[Task Leases](docs/task-leases.md) · [Validate](docs/validation.md) · [Google proof](docs/live-google-validation.md) · [Integration contract](docs/integration-contract.md) · [CLI](docs/cli.md) · [Architecture](docs/architecture.md) · [Roadmap](ROADMAP.md) · [Contributing](CONTRIBUTING.md)
 
-> **Status: public pre-alpha / v0.4.0 Developer Preview.** Published on npm as `@nullsquare/agent-authority`. The repository has a working policy runtime, protocol-neutral guard, Task Lease prototype with provenance-bound derived facts, approvals, revocation, idempotency, credential isolation, MCP v2 gateway, GitHub brokered execution, CI and CodeQL. It is not production-ready yet.
+> **Status: public pre-alpha / v0.4.2 Developer Preview.** Published on npm as `@nullsquare/agent-authority`. The repository has a working policy runtime, protocol-neutral guard, Task Lease prototype, execution-bound derived facts, approvals, revocation, idempotency, credential isolation, MCP v2 gateway, GitHub and Google provider integrations, CI and CodeQL. It is not production-ready yet.
 
 </div>
 
@@ -97,6 +97,12 @@ Human-approved task
   Gmail thread #91
         |
  authorized read
+        |
+        +--> ALLOW receipt
+        +--> exact output hash evidence
+        |
+        v
+ reviewed adapter extractor
         |
         v
  derived fact
@@ -152,12 +158,15 @@ The demo performs this flow without provider credentials:
 
 The side-effect callbacks for blocked actions never run.
 
+The repository also includes a real Gmail → Calendar validation path and a reusable Google provider adapter. The stricter v0.4.2 path binds the derived sender to the exact guarded output before it becomes authority. See [Live Gmail → Calendar validation](docs/live-google-validation.md) and [Executable Evidence](docs/evidence.md).
+
 ## Minimal developer API
 
 ```js
 import { AuthorityRuntime } from '@nullsquare/agent-authority';
 import { createTaskLease } from '@nullsquare/agent-authority/task-lease';
 import { createTaskLeaseGuard } from '@nullsquare/agent-authority/guard';
+import { gmailThreadSenderAuthorityExtractor } from '@nullsquare/agent-authority/providers/google';
 
 const lease = createTaskLease({
   mission,
@@ -169,7 +178,7 @@ const lease = createTaskLease({
     {
       service: 'calendar',
       action: 'event.create',
-      context_field: 'attendee',
+      context_field: 'attendee_email',
       fact_id: 'fact:sender-email'
     }
   ]
@@ -183,25 +192,30 @@ const guard = createTaskLeaseGuard({
 const read = await guard.run({
   service: 'gmail',
   action: 'thread.read',
-  context: { thread: 'thread:demo-91' }
+  context: { thread_id: 'thread:demo-91' }
 }, () => gmail.readThread('thread:demo-91'));
 
-lease.derive({
+const senderFact = lease.deriveFromEvidence({
   fact_id: 'fact:sender-email',
   kind: 'email.address',
-  value: read.output.sender,
   from: ['fact:thread'],
   receipt: read.receipt,
-  selector: 'output.sender'
+  evidence: read.evidence,
+  output: read.output,
+  extractor: gmailThreadSenderAuthorityExtractor
 });
 
 await guard.run({
   service: 'calendar',
   action: 'event.create',
-  context: { attendee: read.output.sender }
-}, () => calendar.createEvent({ attendee: read.output.sender }));
+  context: { attendee_email: senderFact.value }
+}, () => calendar.createEvent({ attendee: senderFact.value }));
 ```
 
+`deriveFromEvidence()` does not accept the authority value. The reviewed extractor selects a normalized output field, and Task Lease resolves that value only after verifying that the output still matches the exact allowed execution evidence.
+
+The older `derive()` API remains available as the explicitly **host-trusted compatibility path**.
+
 The host keeps its existing SDK, connector and authentication. Agent Authority controls whether the effect may happen.
 
 ## Three integration modes, one authority model
@@ -247,7 +261,11 @@ The long-term validation target is the **same Task Lease and authority lineage a
 - Task Lease prototype
 - explicit authority roots
 - same-lease provenance-bound derived facts
-- required parent lineage and trusted extraction selector
+- execution evidence binding an allowed receipt, request and exact output hash
+- strict `deriveFromEvidence()` path where the caller cannot provide the authority value
+- reviewed Gmail sender authority extractor bound to `gmail:thread.read`
+- legacy host-trusted `derive()` compatibility path
+- required parent lineage and extraction selector
 - exact context-field bindings
 - authority-delta step-up signal
 - immediate task completion/expiry enforcement
@@ -257,6 +275,7 @@ The long-term validation target is the **same Task Lease and authority lineage a
 
 - protocol-neutral `guard.run()` wrapper
 - blocked side effects never invoke their callback
+- successful guarded effects return separate execution evidence
 - one-time human approvals bound to exact request
 - mutation idempotency
 - conservative uncertain-state handling
@@ -269,15 +288,19 @@ The long-term validation target is the **same Task Lease and authority lineage a
 - AES-256-GCM local encrypted secret store
 - safe reconnect cleanup
 - GitHub brokered execution without returning the token to the agent
+- Google REST provider mappings for Gmail thread reads and Calendar event mutations
 - short-lived signed local agent-instance tokens
 - local CLI/daemon
 
 ### Engineering quality
 
 - adversarial authorization tests
+- execution-evidence substitution, tampering, replay, cross-lease and selector tests
 - Node 20 and Node 22 CI
 - coverage run
 - package checks
+- clean-consumer npm registry verification
+- live GitHub read and mutation proofs
 - CodeQL
 
 ## What is different from OAuth, IAM and MCP authorization?
@@ -333,7 +356,7 @@ Allow a natural workflow across mail, calendar, CRM and internal systems without
 1. **Task before credential.** A provider token is not task authority.
 2. **Mission is the ceiling.** Task Leases cannot override explicit denies.
 3. **No side effect before authorization.** Denied and step-up actions never execute.
-4. **Authority lineage matters.** Derived facts require an authorized receipt from the same Task Lease, at least one existing parent fact, and a recorded extraction selector.
+4. **Authority lineage matters.** Provider-derived authority should bind the exact allowed receipt and guarded output to a reviewed extractor; legacy host-trusted derivation remains identifiable in provenance.
 5. **No silent resource expansion.** A different concrete resource becomes an authority delta.
 6. **Task authority ends with the task.** Completion and expiry are independent from provider credential lifetime.
 7. **Authority may shrink, never silently grow.** Delegation and transport changes must preserve non-amplification.
@@ -348,7 +371,9 @@ See [SECURITY.md](SECURITY.md).
 This is still a validation implementation.
 
 - Task Lease state is currently process-local.
-- Derived-value extraction is trusted to the host/adapter; v0.4 records the source receipt and selector but does not yet cryptographically prove extraction from the provider response.
+- `deriveFromEvidence()` proves consistency with the exact output returned through the trusted Agent Authority guard, but the output is not cryptographically attested by Gmail, GitHub, or another remote provider.
+- The legacy `derive()` API remains host-trusted for compatibility; audit provenance distinguishes it from `execution-evidence-v1` derivation.
+- Source-data changes do not yet automatically invalidate already-derived authority facts.
 - Bindings currently target top-level request context fields.
 - Approved authority deltas are surfaced but not automatically applied back into a live lease.
 - GitHub token-stdin is a developer bridge, not final browser OAuth onboarding.

package/ROADMAP.md

@@ -77,19 +77,25 @@ Build only what the real M1 workflow proves necessary.
 
 **Success criterion:** a Task Lease survives daemon/process restarts without gaining authority or losing its provenance lineage.
 
-## M3 — Trustworthy derived facts
+## M3 — Trustworthy derived facts — two-provider proof established
 
-Today the trusted host/adapter supplies the derived value and selector. This is an explicit v0.4 limitation.
+The first real Gmail -> Calendar integration showed that recording a host-supplied value plus selector was too weak for the strongest derived-authority claim. The compatibility `derive()` path remains host-trusted; new provider work should prefer execution-bound evidence and reviewed adapter extractors.
 
-- [ ] define a small adapter contract for extracting authority-relevant fields from provider results
-- [ ] bind derived fact records to provider/result evidence where practical
-- [ ] adversarial tests for forged extraction, confused-deputy mappings and stale facts
-- [ ] conformance fixture for operation -> resource-context mappings
-- [ ] define invalidation rules when a source resource changes
+- [x] define a small trusted-adapter extractor contract for authority-relevant normalized provider fields
+- [x] bind successful guarded outputs to the exact ALLOW receipt, request and output hash
+- [x] add `TaskLease.deriveFromEvidence()` so the caller cannot provide the authority value
+- [x] migrate Gmail sender -> Calendar attendee derivation to the evidence-verified path
+- [x] migrate the real GitHub issue discovery -> comment mutation proof to the same evidence-verified path
+- [x] adversarial tests for value substitution, output/evidence tampering, receipt replay, cross-lease reuse, wrong-operation extraction and dangerous selectors
+- [x] shared conformance fixtures for reviewed operation -> authority-field mappings across Google and GitHub
+- [ ] define provider/result attestation stronger than a trusted host output hash where practical
+- [ ] define freshness/invalidation rules when a source resource changes
+
+The shared contract is documented in `docs/authority-extractor-conformance.md`. Google and GitHub now use the same `guard.run()` -> execution evidence -> reviewed extractor -> `deriveFromEvidence()` primitive, and the same conformance suite attacks both mappings.
 
 Do **not** build a general semantic policy language unless real integrations require it.
 
-**Success criterion:** an adapter cannot claim a value was derived from an authorized operation without satisfying the documented extraction/evidence contract.
+**Success criterion:** provider-derived authority cannot be established through the strict path unless the exact guarded output, ALLOW receipt and reviewed extractor contract agree on the selected value. This behavior is now exercised across two provider mappings. Stronger provider attestation and source invalidation remain separate follow-on problems.
 
 ## M4 — Same task, multiple transports
 
@@ -147,7 +153,7 @@ Only after operational evidence.
 
 ## Research questions
 
-1. What is the smallest trustworthy representation of an authority-relevant derived fact?
+1. What provider-side or transport-side evidence can strengthen output integrity without turning Agent Authority into an attestation protocol?
 2. How should an approved authority delta update a running task without opening a broader wildcard permission?
 3. How should source-data changes invalidate downstream derived authority?
 4. What provider/tool metadata is required to map operations to resource context reliably?

package/docs/authority-extractor-conformance.md

@@ -0,0 +1,95 @@
+# Authority extractor conformance
+
+Agent Authority treats provider-derived authority as a small adapter contract, not a general semantic policy language.
+
+The strict path is:
+
+```text
+authorized request
+      |
+      v
+reviewed provider adapter
+      |
+      v
+normalized provider output
+      |
+      +--> ALLOW receipt
+      +--> execution output hash
+      |
+      v
+adapter.authorityExtractor(request, factKind)
+      |
+      v
+{ extractor_id, selector }
+      |
+      v
+TaskLease.deriveFromEvidence()
+      |
+      v
+derived authority fact
+```
+
+## Adapter requirements
+
+A provider mapping intended to establish downstream authority SHOULD satisfy all of these:
+
+1. **Reviewed operation mapping.** The adapter owns the mapping from Agent Authority `service` + `action` to the external provider operation.
+2. **Normalized authority field.** Provider data is normalized into a small output shape before authority extraction. Credentials and unrelated raw payloads should not be copied into the authority result.
+3. **Fail-closed extractor advertisement.** `adapter.authorityExtractor(request, factKind)` returns an extractor only for an explicitly supported operation/fact-kind pair. Unsupported mappings return `null`.
+4. **Selector, never value.** The extractor returns `{ extractor_id, selector }`. It must not return the derived authority value itself.
+5. **Operation binding.** The extractor rejects receipts from another provider action.
+6. **Canonical output.** The extractor rejects malformed, ambiguous, or non-canonical normalized output.
+7. **Task lineage.** `TaskLease.deriveFromEvidence()` requires an ALLOW receipt from the same mission and Task Lease plus at least one existing parent fact.
+8. **Exact-output integrity.** The output passed to derivation must still hash to the output bound into the execution evidence.
+
+This is an integrity contract inside the trusted Agent Authority host/adapter boundary. It is not provider-signed remote attestation.
+
+## Current fixtures
+
+### Google Gmail sender
+
+```text
+gmail:thread.read
+  -> normalized sender_email
+  -> google.gmail.thread.sender-email.v1
+  -> email.address
+```
+
+The Gmail extractor accepts only canonical normalized `sender_email` output and selects `output.sender_email`.
+
+### GitHub selected issue
+
+```text
+github:issue.list
+  + root-bound repository
+  + root-bound fixture_marker
+  -> exactly one normalized marker match
+  -> github.issue.list.selected-number.v1
+  -> github.issue.number
+```
+
+The GitHub adapter performs marker matching against the provider response, does not expose issue bodies in the normalized output, and the extractor selects only `output.selected_issue_number` when exactly one non-pull-request issue matched.
+
+## Shared adversarial conformance suite
+
+`test/provider-authority-conformance.test.js` applies the same strict-path checks to both provider fixtures:
+
+- positive derivation obtains the value from the evidence-bound output rather than caller input;
+- modified output under unchanged evidence is rejected;
+- execution evidence cannot be replayed under a second ALLOW receipt;
+- receipt/evidence from one Task Lease cannot establish authority in another lease;
+- an extractor cannot be reused with evidence from another provider operation.
+
+Provider-specific tests additionally verify canonical normalization, exact REST mappings, extractor advertisement, and ambiguity failure.
+
+## What conformance does not prove
+
+Passing this contract does not prove that:
+
+- a provider cryptographically signed the normalized result;
+- the trusted host itself is non-malicious;
+- a source resource has not changed since the read;
+- a derived fact is automatically invalidated when provider data changes;
+- an agent cannot bypass Agent Authority through a separate credential or unguarded provider path.
+
+Those are separate trust, freshness, and deployment-boundary problems and should not be hidden inside the extractor API.

package/docs/evidence.md

@@ -10,9 +10,85 @@ This page records the strongest properties the repository currently demonstrates
 
 The guarantee applies to effects that actually pass through the Agent Authority enforcement boundary. A separate unguarded provider path is outside this guarantee.
 
+## Execution-bound derived authority
+
+The strict derived-authority path binds provider-derived authority to the exact output returned by an authorized `guard.run()` effect.
+
+A successful guarded effect returns three relevant records:
+
+```text
+ALLOW receipt
+    +
+exact effect output
+    |
+    v
+execution evidence
+(receipt + request + output hash)
+    |
+    v
+reviewed adapter extractor
+(selector only, no value)
+    |
+    v
+TaskLease.deriveFromEvidence()
+    |
+    v
+derived authority fact
+```
+
+`deriveFromEvidence()` does not accept the derived authority value. The trusted adapter extractor chooses a reviewed selector, and Task Lease resolves that selector itself only after verifying the execution evidence.
+
+`test/authority-evidence.test.js` attacks this boundary directly and proves that:
+
+- caller-supplied value substitution does not control the resulting fact;
+- modified provider output is rejected with `evidence_output_mismatch`;
+- modified execution-evidence contents are rejected;
+- evidence cannot be replayed under a second ALLOW receipt;
+- a receipt/evidence chain from another Task Lease is rejected;
+- the Gmail sender extractor rejects the wrong provider operation;
+- dangerous selector paths such as `__proto__` fail closed.
+
+The legacy `TaskLease.derive()` API remains for compatibility and records `derivation_mode: host-trusted`. New provider-derived authority should prefer `deriveFromEvidence()`, which records `derivation_mode: execution-evidence-v1`, extractor ID, source output hash, and execution-evidence hash.
+
+### Boundary of this claim
+
+Execution evidence is an integrity mechanism inside the trusted host/runtime boundary. It proves that the value selected for strict derivation came from the exact output object bound to that Agent Authority receipt.
+
+It does **not** prove that Gmail, GitHub, or another provider cryptographically signed that output, and it does not protect a malicious host that bypasses or replaces the Agent Authority enforcement path. Stronger provider/transport attestation remains open M3 work.
+
+## Two-provider authority-extractor conformance
+
+The same strict primitive is now exercised by two independent provider mappings:
+
+```text
+Google Gmail
+thread.read
+   -> sender_email
+   -> reviewed extractor
+   -> email.address authority
+
+GitHub
+issue.list
+   -> selected_issue_number
+   -> reviewed extractor
+   -> github.issue.number authority
+```
+
+`test/provider-authority-conformance.test.js` applies the same contract to both mappings:
+
+- positive derivation gets its value from the evidence-bound output rather than caller input;
+- modifying the selected output under unchanged evidence is rejected;
+- evidence replay under another ALLOW receipt is rejected;
+- cross-Task-Lease receipt/evidence reuse is rejected;
+- an extractor rejects evidence from another operation.
+
+Provider-specific tests additionally verify canonical normalization and fail-closed extractor advertisement. The contract is documented in [Authority extractor conformance](authority-extractor-conformance.md).
+
+This is the current evidence that execution-bound derived authority is a reusable provider primitive rather than a Gmail-only special case.
+
 ## Cross-provider derived authority — Gmail → Calendar
 
-Agent Authority now includes a real Google provider mapping, an adversarial cross-provider test, a live validation script, and an opt-in GitHub Actions workflow.
+Agent Authority includes a real Google provider mapping, an adversarial cross-provider test, a live validation script, and an opt-in GitHub Actions workflow.
 
 The task shape is:
 
@@ -22,9 +98,11 @@ one Gmail thread
         |
         v
 ALLOW Gmail thread.read
+        |
+        +--> output-bound execution evidence
         |
         v
-discover sender email
+trusted Gmail sender extractor
         |
         v
 derive fact: sender_email
@@ -57,19 +135,21 @@ A controlled self-test was exercised against the connected NullSquare Gmail and
 
 No unrelated external person was invited. The smoke test establishes that the concrete Gmail and Calendar operations used by the validation are available and compatible with the intended data shape.
 
-The live connected-account smoke is not presented as a public CI proof of the repository script. The Task Lease zero-call assertions are separately executable in `test/google-cross-provider.test.js`, and `.github/workflows/live-google-validation.yml` is provided for a rerunnable provider-backed proof once repository Google OAuth secrets are configured.
+The live connected-account smoke is not presented as a public CI proof of the repository script. The Task Lease zero-call and execution-evidence assertions are separately executable in `test/google-cross-provider.test.js` and `test/authority-evidence.test.js`, and `.github/workflows/live-google-validation.yml` is provided for a rerunnable provider-backed proof once repository Google OAuth secrets are configured.
 
 ### Executable local/CI assertions
 
 `test/google-cross-provider.test.js` proves deterministically that:
 
 - the approved Gmail thread callback runs exactly once;
-- its sender becomes a same-lease derived authority fact;
+- its sender becomes a same-lease `execution-evidence-v1` authority fact;
 - one Calendar mutation for that sender runs exactly once;
 - a different attendee produces `authority_delta_required` and the Calendar callback is not invoked;
 - after lease completion, the previously valid attendee produces `task_lease_completed` and the Calendar callback is not invoked again.
 
-`test/google-provider.test.js` separately validates the Google REST mappings, metadata-only Gmail sender extraction, Calendar attendee body, default `sendUpdates=none`, credential redaction, unsupported-action failure, and mutation classification.
+`test/google-provider.test.js` validates the Google REST mappings, metadata-only Gmail sender extraction, Calendar attendee body, default `sendUpdates=none`, credential redaction, unsupported-action failure, and mutation classification.
+
+`test/google-authority-extractor.test.js` separately verifies that the reviewed Gmail extractor only accepts canonical `gmail:thread.read` sender output and that the Google adapter advertises it only for the supported authority mapping.
 
 ### Public workflow
 
@@ -89,9 +169,10 @@ The connected GitHub tool does not expose repository Actions-secret management,
 
 ### What this proves
 
-Taken together, the deterministic Task Lease test plus the controlled provider smoke show that:
+Taken together, the deterministic Task Lease tests plus the controlled provider smoke show that:
 
 - the Gmail → Calendar derived-authority shape is implemented, not just diagrammed;
+- strict derivation binds the sender to the exact guarded Gmail output before it becomes authority;
 - the exact attendee binding is enforced before the Calendar mutation callback;
 - provider operations exist and work against real Gmail and Calendar accounts;
 - cleanup can keep the live proof reversible and self-contained.
@@ -99,20 +180,21 @@ Taken together, the deterministic Task Lease test plus the controlled provider s
 ### What this does not prove yet
 
 - a public GitHub Actions run has executed the full repository live script;
-- host-side extraction of `sender_email` is cryptographically attested by Gmail;
+- `sender_email` is cryptographically attested by Gmail rather than integrity-bound to the trusted host's guarded output;
 - the agent cannot bypass Agent Authority if it independently holds a Google credential;
 - Task Lease state is durable across process failure;
+- source-data changes automatically invalidate downstream facts;
 - the refresh-token setup is production credential onboarding.
 
 See [Live Gmail → Calendar validation](live-google-validation.md).
 
-## Live derived-authority mutation — GitHub
+## Live evidence-derived mutation — GitHub
 
 Public fixture: [issue #9](https://github.com/Null-Square/agent-authority/issues/9)
 
 Validation workflow: CI job `live-derived-github-mutation`
 
-Passing run: [CI run 136](https://github.com/Null-Square/agent-authority/actions/runs/32517381668)
+Passing evidence-derived run: [CI run 262](https://github.com/Null-Square/agent-authority/actions/runs/32600963479)
 
 The job uses a GitHub Actions token with:
 
@@ -121,25 +203,40 @@ contents: read
 issues: write
 ```
 
-The Task Lease itself starts with only the repository as an authority root.
+The Task Lease begins with two explicit authority roots:
+
+```text
+repository = Null-Square/agent-authority
+fixture_marker = agent-authority-live-fixture-v1
+```
+
+Both values are bound to the `issue.list` request. The brokered GitHub provider adapter owns the external issue-list operation and normalizes the provider response. Issue bodies are used internally for marker matching but are not copied into the normalized authority output.
 
 ### Executed path
 
 ```text
-Task root
-Null-Square/agent-authority
+Task roots
+repository + fixture marker
+        |
+        v
+ALLOW github:issue.list
+through reviewed provider adapter
+        |
+        +--> exact output-bound execution evidence
         |
         v
-ALLOW live issue-list request
+adapter selects exactly one marker match
+selected_issue_number = 9
         |
         v
-discover issue #9 from GitHub response
+reviewed GitHub issue-number extractor
         |
         v
-derive fact: issue_number = 9
+TaskLease.deriveFromEvidence()
+issue_number = 9
         |
         v
-ALLOW one real comment mutation on #9
+ALLOW one real github:issue.comment on #9
         |
         +--> attempt comment on #1
         |      -> authority_delta_required
@@ -156,38 +253,41 @@ complete Task Lease
 The passing job recorded:
 
 ```text
-ALLOW -> discovered issue #9
-Derived authority -> issue #9
+ALLOW -> selected issue #9: Agent Authority live validation fixture — do not close
+Evidence-verified authority -> issue #9
 ALLOW -> real GitHub comment mutation executed
 STEP-UP -> unrelated issue #1 blocked before provider mutation
 DENY -> post-completion mutation blocked for issue #9
+PASS -> GitHub provider output became downstream authority only through execution evidence and a reviewed extractor
 Provider calls observed before cleanup: reads=1, task_mutations=1
 ```
 
-The temporary validation comment is deleted by test-harness cleanup after the proof. Cleanup is intentionally outside the agent authority path and counted separately.
+The temporary validation comment was deleted by harness cleanup after the proof. Cleanup remains intentionally outside the Task Lease authority path and is counted separately.
 
 ### What this proves
 
-- a concrete resource can be discovered from a real provider response during authorized execution;
-- that resource can become same-lease derived authority;
-- a real provider mutation can be limited to the derived resource;
-- asking for another resource does not silently inherit the same authority;
-- a blocked resource causes zero additional task-side provider mutation calls;
-- completing the Task Lease prevents reuse of the previously authorized resource;
-- the provider credential can still exist after task authority disappears.
+- the same execution-evidence + reviewed-extractor primitive used for Gmail works against a second real provider;
+- the brokered GitHub adapter, rather than arbitrary host extraction code, owns provider response normalization;
+- the caller does not provide the issue number to `deriveFromEvidence()`;
+- repository and discovery marker are explicit Task Lease roots;
+- a real provider mutation is limited to the issue selected from the authorized provider result;
+- another issue causes zero additional task-side provider mutation calls;
+- completing the Task Lease prevents reuse of the previously authorized issue;
+- the provider credential can remain valid after task authority disappears.
 
 ### What this does not prove
 
-- the host/adapter's extraction of `output.number` is cryptographically verified;
+- GitHub cryptographically attests the normalized Agent Authority output;
+- source issue changes automatically invalidate a derived fact;
 - an agent cannot bypass Agent Authority if it independently possesses the provider credential or another unguarded provider path;
 - Task Lease state is durable across process failure;
 - the current prototype is ready for adversarial production use.
 
 ## Live provider read boundary — GitHub
 
-CI also runs `demo:live-github` against the public GitHub API.
+CI also runs `demo:live-github` against the GitHub API.
 
-It proves that one repository permitted by the Task Lease causes one live `fetch()` while another repository produces `authority_delta_required` before a second fetch occurs.
+It proves that one repository permitted by the Task Lease causes one live provider read while another repository produces `authority_delta_required` before a second provider request occurs.
 
 ## Network-boundary integration test
 
@@ -209,7 +309,9 @@ The test suite also covers:
 - receipts from another mission are rejected;
 - receipts from another Task Lease are rejected;
 - parent lineage is required;
-- a trusted extraction selector must be recorded;
+- legacy host-trusted derivation records its extraction selector;
+- strict execution-evidence derivation rejects substitution/replay/tampering cases;
+- the shared provider conformance suite applies the same attacks to Google and GitHub mappings;
 - explicit mission deny rules remain the ceiling;
 - lease expiry and mission expiry are enforced against a consistent evaluation clock.
 
@@ -224,8 +326,8 @@ Current pull requests run:
 - package checks;
 - coverage;
 - live GitHub read validation;
-- live derived GitHub mutation validation for trusted in-repository branches;
-- Google provider and cross-provider adversarial tests;
+- live evidence-derived GitHub mutation validation for trusted in-repository branches;
+- Google and GitHub provider/extractor conformance and execution-evidence adversarial tests;
 - CodeQL.
 
 The live Google provider mutation workflow is manual because it requires repository-owned Google OAuth secrets. It should be added to the public evidence list after its first successful run.

package/docs/npm-release.md

@@ -13,17 +13,19 @@ Before any publication:
 After publication, verify from a fresh project with:
 
 ```bash
-npm install @nullsquare/agent-authority@0.4.0
+npm install @nullsquare/agent-authority@0.4.2
 ```
 
 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 also includes `.github/workflows/verify-npm-registry.yml`, which verifies registry visibility and a clean consumer install. For v0.4.2 it additionally verifies the public `@nullsquare/agent-authority/authority-evidence` export plus the Google provider and Gmail authority-extractor exports.
+
 ## 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.0`. 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.2`. 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.