Walking skeleton: verify and execute one temporary successor release through authenticated bindings

[chronoai-fkst]

Objective

Implement the thinnest executable end-to-end successor-release path: generate one temporary signed testing-package-release.v1, authenticate and policy-check it, verify its bound artifacts, derive dispatch exclusively from verified return values, execute the existing testing_package_executor.executor.execute, and validate the complete passing ResultAuthority receipt.

This is a Cockburn walking skeleton, not a scaffold. Use real generator, signing, verification, artifact loading, executor, reducer, and ResultAuthority code. Write the smoke/acceptance test in this PR and leave it green.

Do not implement the full rejection matrix, production publication, Runtime policy persistence, key rotation, revocation transport, browser lifecycle, or parallel implementations. If the required architectural seam does not exist and no mergeable executable diff can be produced, make no changes and report the precise reason; no changes are fatal and block this work.

Bounded behavior

One deterministic temporary successor release must complete this real path:

1. Generate the release and all bound artifacts under a fresh temporary root.
2. Independently calculate the exact release and authorization SHA-256 values.
3. Verify the release digest, authority policy, trusted authorization, Ed25519 DSSE signature, exact release subject, and dependent artifact bindings in the mandatory order below.
4. Return verified tool and dispatch bindings from verification.
5. Pass those returned bindings into executeVerified.
6. Resolve and call only the returned module and function.
7. Expose only the returned port and bind it to the returned capability and execution profile.
8. Execute the existing browser-title flow with deterministic in-memory ports.
9. Validate the complete passing ResultAuthority receipt with contract.testing_result_authority.validate_receipt.

Deterministic acceptance profile

Use these exact values:

• Source commit: 1111111111111111111111111111111111111111
• fkst-packages commit: 2222222222222222222222222222222222222222
• fkst-substrate commit: 3333333333333333333333333333333333333333
• Authority issuer: https://releases.chronoaiproject.org/fkst-packages-testing
• Authority key ID: fkst-packages-testing-successor-test-v1
• Signature profile: dsse-ed25519.v1
• Validity start: 2026-09-04T00:00:00Z
• Validity end: 2026-09-05T00:00:00Z
• Verification time: 2026-09-04T12:00:00Z
• Revocation-authority identity: https://releases.chronoaiproject.org/fkst-packages-testing/revocations/v1
• Release sequence: 2
• Minimum accepted release sequence: 2
• Created time: 2026-09-04T00:00:00Z
• Test-only signing seed, canonical standard base64 for the 32 bytes 00 through 1f: AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=

Name and document the seed as non-production/test-only. The release is accepted because 2 >= 2, 2026-09-04T12:00:00Z lies in the half-open interval 2026-09-04T00:00:00Z <= time < 2026-09-05T00:00:00Z, and the key is not revoked.

Successor release contract

Keep schema = "testing-package-release.v1" and canonicalization = "fkst-testing-package-release-canonical-json.v1". Preserve all existing closed release members and identities. A successor release adds both authority and tool_catalog; either both are present or neither is present.

Exact authority member:

"authority":{"issuer":"https://releases.chronoaiproject.org/fkst-packages-testing","keyid":"fkst-packages-testing-successor-test-v1","release_sequence":2,"revocation_authority":"https://releases.chronoaiproject.org/fkst-packages-testing/revocations/v1","signature_profile":"dsse-ed25519.v1","valid_from":"2026-09-04T00:00:00Z","valid_until":"2026-09-05T00:00:00Z"}

Exact tool-catalog binding shape:

"tool_catalog":{"path":"package-release/testing-package-tool-catalog.v1.json","sha256":"<64 lowercase hexadecimal SHA-256 of the exact catalog bytes>","size_bytes":<positive safe integer exact byte length>}

authority is closed and contains exactly issuer, keyid, release_sequence, revocation_authority, signature_profile, valid_from, and valid_until.

Required rules for this accepted path:

• issuer equals https://releases.chronoaiproject.org/fkst-packages-testing.
• signature_profile equals dsse-ed25519.v1.
• revocation_authority equals https://releases.chronoaiproject.org/fkst-packages-testing/revocations/v1.
• keyid is valid Unicode scalar text whose UTF-8 encoding is 1..128 bytes, contains no Unicode control category Cc, and equals both the authorization key ID and the sole DSSE signature key ID.
• release_sequence is a JSON integer from 1 through 9007199254740991 inclusive.
• Timestamps use exactly YYYY-MM-DDTHH:MM:SSZ: four-digit year, two-digit month/day/hour/minute/second, uppercase T and Z, no fractional seconds, and no numeric offset.
• The validity interval is half-open: acceptance requires valid_from <= verification_time < valid_until.

Preserve and cross-check these identities:

• Package ID: testing-runner
• Supported profile: browser-deterministic.v1
• Capability: browser.read-title.v1
• Sole mapping: {"contract_major":"testing-runner.v1","entrypoint":"testing-runner.run","function":"execute","module":"testing_package_executor.executor"}
• Executor: {"executor_id":"testing-package-executor.browser-title.v1","function":"execute","module":"testing_package_executor.executor"}
• Reducer schema: testing-assertion-reducer-identity.v1
• Reducer ID: testing.assertion-reducer.browser-title-equals
• Reducer version: 1.0.0
• Reducer policy profile: browser-title-equals.v1
• Reducer supported result contract: exactly testing-case-result-set.v2
• reducer_sha256: SHA-256 over canonical reducer identity bytes with reducer_sha256 absent and no final LF
• ResultAuthority receipt schema: testing-result-authority-receipt.v1
• ResultAuthority validator: contract.testing_result_authority.validate_receipt

Tool catalog contract

The only accepted logical path is package-release/testing-package-tool-catalog.v1.json. Its complete semantic value is:

{"canonicalization":"fkst-testing-package-tool-catalog-canonical-json.v1","execution_profile":"browser-deterministic.v1","schema":"testing-package-tool-catalog.v1","tools":[{"capability":"browser.read-title.v1","port":"browser_read_title"}]}

Persist exactly that compact JSON followed by one LF byte. Object keys are recursively lexicographically sorted, array order is significant, and tools contains exactly one element. The release binds the exact logical path, byte length, and SHA-256. Verify these bindings and cross-check the capability and execution profile against the release identity before extraction or module loading.

Canonical bytes and DSSE grammar

Release, tool-catalog, authorization, envelope, bundle, and other release metadata JSON use valid UTF-8, recursively lexicographically sorted object keys, compact separators with no insignificant whitespace, and exactly one final LF. Arrays retain declared order. The package manifest retains fkst-testing-package-manifest-canonical-json.v1 and has no final LF.

JSON strings escape quote, reverse solidus, backspace, tab, LF, form feed, and carriage return as \", \\, \b, \t, \n, \f, and \r. Remaining U+0000 through U+001F characters use lowercase four-hex-digit \u00xx.

SHA-256 values are exactly 64 lowercase hexadecimal characters. Standard base64 uses alphabet A-Z, a-z, 0-9, +, /, required = padding, and no whitespace; decoding and re-encoding must reproduce the identical string.

Authorization is closed and has exactly this shape:

{"algorithm":"ed25519","authorization":{"payloadType":"application/vnd.in-toto+json","predicateType":"https://chronoaiproject.github.io/fkst-packages-testing/attestations/testing-package-release/v1","subject":"package-release/testing-package-release.v1.json"},"keyid":"fkst-packages-testing-successor-test-v1","publicKey":"<canonical standard base64 of exactly 32 Ed25519 public-key bytes>","schema":"testing-package-release-key-authorization.v1"}

The detached envelope is closed and has exactly this shape:

{"payload":"<canonical standard base64 DSSE statement>","payloadType":"application/vnd.in-toto+json","signatures":[{"keyid":"fkst-packages-testing-successor-test-v1","sig":"<canonical standard base64 of exactly 64 Ed25519 signature bytes>"}]}

The decoded payload is compact canonical JSON with no final LF and exactly this shape:

{"_type":"https://in-toto.io/Statement/v1","predicate":{},"predicateType":"https://chronoaiproject.github.io/fkst-packages-testing/attestations/testing-package-release/v1","subject":[{"digest":{"sha256":"<SHA-256 of exact release bytes including final LF>"},"name":"package-release/testing-package-release.v1.json"}]}

Sign and verify exactly these DSSE pre-authentication encoding bytes:

DSSEv1 <decimal UTF-8 byte length of payloadType> <payloadType UTF-8 bytes> <decimal payload byte length> <payload bytes>

There is one ASCII space after DSSEv1, between each decimal length and value, and between the payload type and payload length. Decimal lengths have no sign or leading zeroes unless the length is zero.

Existing interfaces

Extend and use the existing generator; do not create another generator:

python3 scripts/generate_testing_package_release.py --output-directory <temp-root> --seed-file <test-seed-file> --source-commit 1111111111111111111111111111111111111111 --fkst-packages-commit 2222222222222222222222222222222222222222 --fkst-substrate-commit 3333333333333333333333333333333333333333 --authority-issuer https://releases.chronoaiproject.org/fkst-packages-testing --authority-keyid fkst-packages-testing-successor-test-v1 --signature-profile dsse-ed25519.v1 --valid-from 2026-09-04T00:00:00Z --valid-until 2026-09-05T00:00:00Z --revocation-authority https://releases.chronoaiproject.org/fkst-packages-testing/revocations/v1 --release-sequence 2 --created-at 2026-09-04T00:00:00Z

Generate under <temp-root> at least:

package-release/testing-package-bundle.v1.json
package-release/testing-package-manifest.v1.json
package-release/testing-package-release.v1.json
package-release/testing-package-release.v1.dsse.json
package-release/testing-package-release.v1.key.json
package-release/testing-package-tool-catalog.v1.json

Logical paths inside signed data remain repository-relative forward-slash paths, never absolute temporary paths.

Extend and use the existing verifier; do not create another verifier. Preserve explicit artifact path options and mandatory --expected-release-sha256 and --trusted-authorization-sha256. Use this successful invocation shape:

node scripts/verify_testing_package_release.mjs --expected-release-sha256 <SHA-256 of exact temporary release bytes> --trusted-authorization-sha256 <SHA-256 of exact temporary authorization bytes> --verification-time 2026-09-04T12:00:00Z --minimum-release-sequence 2 --release <temp-root>/package-release/testing-package-release.v1.json --envelope <temp-root>/package-release/testing-package-release.v1.dsse.json --authorization <temp-root>/package-release/testing-package-release.v1.key.json --bundle <temp-root>/package-release/testing-package-bundle.v1.json --manifest <temp-root>/package-release/testing-package-manifest.v1.json --tool-catalog <temp-root>/package-release/testing-package-tool-catalog.v1.json --schema-catalog <schema-catalog-path> --schema-release <schema-release-path>

All options are unique --name value pairs except repeatable --revoked-keyid; no revoked key is supplied in this positive test. --verification-time uses the timestamp grammar above. --minimum-release-sequence uses ^[1-9][0-9]*$ and must not exceed 9007199254740991.

Mandatory authenticated gate order

The walking skeleton must use this order even though this child only proves the successful path:

1. Parse and validate the complete CLI grammar with zero artifact reads.
2. Read only the exact release bytes, calculate SHA-256, and compare it with --expected-release-sha256.
3. Parse and canonical-check the release, then validate authority identity, validity interval, release-sequence floor, and revoked-key policy.
4. Read authorization bytes, enforce --trusted-authorization-sha256, validate canonical/profile/key-ID rules, and import the authorized public key.
5. Read only the DSSE envelope; validate canonical/profile/key-ID rules and the signature, then validate the canonical statement and exact release-subject digest.
6. Only after DSSE and subject verification may the verifier read or stat the manifest, bundle, tool catalog, schema catalog, or schema release and verify their logical paths, exact bytes, digests, sizes, schemas, identities, and cross-bindings.
7. Only after all dependent artifacts verify may code be extracted or materialized, modules loaded, or the executor invoked.

Do not use a pre-DSSE Promise.all or any equivalent eager dependent-artifact read.

Verified dispatch seam

Verification must return, rather than merely compare and discard, these exact values:

• Tool-catalog verification returns { capability, port, executionProfile }.
• Release/mapping verification returns { entrypoint, contractMajor, module, function, executorId }.

Pass both returned bindings into executeVerified and into any isolated Lua execution harness. Resolve/require and call only the returned module and function. Expose only the returned port, bound to the returned capability and executionProfile. The entrypoint, contract major, executor ID, capability, port, and execution profile used to construct the invocation must all come from these verified return values.

Do not retain executable parallel defaults such as a separate selected_entrypoint, hardcoded testing_package_executor.executor, hardcoded execute, or hardcoded browser_read_title after verification.

For this accepted release, the returned bindings are exactly:

{ capability: "browser.read-title.v1", port: "browser_read_title", executionProfile: "browser-deterministic.v1" }
{ entrypoint: "testing-runner.run", contractMajor: "testing-runner.v1", module: "testing_package_executor.executor", function: "execute", executorId: "testing-package-executor.browser-title.v1" }

ResultAuthority acceptance

Use deterministic in-memory ports and produce a passing testing-result-authority-receipt.v1. Validate the complete receipt through contract.testing_result_authority.validate_receipt, including bound artifacts and its SHA-256 function; checking only receipt.schema is not sufficient.

The receipt is closed and contains exactly these fields:

schema, canonicalization, receipt_id, run_id, invocation_id, admitted_release_ref, admission_digest, package_id, package_version, package_content_sha256, manifest_digest, executor_id, structured_plan_ref, reducer, case_result_set_ref, case_result_set_content_sha256, evidence_manifest_ref, evidence_manifest_content_sha256, completed_execution_sha256, classification, receipt_sha256

Require:

• schema = "testing-result-authority-receipt.v1"
• canonicalization = "fkst-testing-result-authority-canonical-json.v1"
• classification = "passed"
• Package, manifest, executor, and reducer identities match the verified artifacts and identities listed above.
• References have closed shape {"kind":"<non-empty bounded UTF-8>","ref":"<non-empty bounded UTF-8>","sha256":"<64 lowercase hex>"}.
• receipt_sha256 is SHA-256 over canonical receipt bytes with receipt_sha256 temporarily set to 64 lowercase zeroes.
• Persisted receipt JSON uses recursively sorted keys, compact encoding, and exactly one final LF.

Acceptance test

Add one focused smoke/acceptance test that:

• Creates a fresh temporary root and writes the exact non-production seed to a temporary seed file.
• Runs the real generator with the exact arguments above.
• Calculates release and authorization digests independently from exact file bytes.
• Runs the real verifier with the exact invocation shape above and no revoked key.
• Proves dependent artifact verification completes before extraction, module loading, or execution.
• Captures the two verified binding objects and passes those exact objects into executeVerified.
• Uses a deterministic in-memory implementation of only browser_read_title; records that it is called and that no unverified port is exposed.
• Proves testing-runner.run resolves only testing_package_executor.executor.execute and uses executor ID testing-package-executor.browser-title.v1.
• Executes the existing reducer and validates the complete passing receipt with contract.testing_result_authority.validate_receipt.
• Snapshots exact bytes and SHA-256 for currently committed package-release/ files and current schema-release bindings before the test, then proves they remain byte-identical afterward.
• Proves every generated file remains beneath the fresh temporary root.

Non-goals

• Do not add the full negative or mutation matrix; later slices own malformed time, revocation, sequence, shape, catalog, identity, exact-release mismatch, and invalid-signature regressions.
• Do not publish or replace committed release, envelope, authorization, bundle, manifest, source-pin, schema-catalog, or schema-release bytes.
• Do not access, infer, replace, or counterfeit a production signing seed.
• Do not create parallel generators, release formats, verifiers, runners, executors, reducers, result authorities, resolvers, or Runtime state.
• Do not add policy storage, fetching, caching, rotation, revocation transport, browser lifecycle, or a coverage allowlist entry.

Acceptance criteria

• One temporary successor release is generated, signed, authenticated, policy-accepted, artifact-verified, executed, reduced, and receipt-validated through real code.
• Verification returns both exact binding objects and execution consumes only those returned values.
• Only testing_package_executor.executor.execute is loaded and only browser_read_title is exposed and called.
• The complete passing ResultAuthority receipt validates, including all artifact bindings and receipt_sha256.
• The authenticated gate order prevents dependent reads or executable activity before their successful prerequisite gates.
• Committed signed artifacts remain byte-identical and all generated files stay under the temporary root.
• The focused acceptance test and affected existing tests pass, and git diff --check is clean.

[chronoai-fkst]

👀 Picked up by fkst session mvp-integration.

A fkst pod is working this repo's fkst-dev-chronoai-fkst-cloud issues, including this one. The session posts its progress on this issue as it works, and the outcome will be a pull request (or, for issue-producing sessions, linked issues).

[chronoai-fkst]

github-devloop thinking: consensus started

[chronoai-fkst]

github-devloop convergence round 0 - no consensus across angles; narrowing

Narrowed question: publisher-authenticated module, function, and port are incorrectly treated as local execution authority + resolve by narrowing verification to semantic identities consumed by contract.testing_package_executor.semantic_mappings, or provide a superseding normative contract and implementation proving publisher-selected coordinates are locally authorized

Angle stances:

• teleology: abstain — Established trusted-update practice separates artifact authentication from local execution authorization: verified publisher facts enter a complete-mediation reference monitor, which selects a locally supported capability and implementation. The repository makes that governing rule explicit: contract.testing_package_executor.semantic_mappings is the closed compatibility registry, and paths, dynamic imports, and plugins are not mapping inputs (contracts/testing-package-resolution.v1.md:12, contracts/testing-package-resolution.v1.md:24). The resolver verifies semantic identities, selects e
• parsimony: abstain — Established trusted-update/reference-monitor practice separates authentication of publisher metadata from local authorization of executable behavior: verified metadata may identify semantic requirements, but the consumer must mediate them through its locally supported registry. The proposal’s root claim violates that boundary by making signed module, function, and port strings the sole dispatch authority. The repository explicitly assigns semantic target selection to the resolver and gives the executor only a resolved semantic identity and bounded ports (`contracts/testing-package-reso
• fidelity: abstain — Established trusted-update/reference-monitor practice separates publisher authentication from consumer authorization: verified semantic identity is mapped by a local closed registry, not used as publisher-selected executable coordinates. The proportional-containment peer’s evidence strengthens the root blocker: Walking skeleton: verify and execute one temporary successor release through authenticated bindings #807 mandates that returned module, function, and port values exclusively drive loading and dispatch, but the repository assigns semantic target selection to the Runtime resolver (contracts/testing-package-resolution.v1.md:3) through `contract.testing_package_executor.semantic
• natural-ownership: abstain — The root claim remains blocked under established trusted-update reference-monitor, complete-mediation, and least-authority practice. The proposal makes authenticated publisher strings for module, function, and port executable authority and requires removing local dispatch defaults, but the governing contract assigns semantic target selection to the Runtime’s closed compatibility registry and explicitly excludes dynamic imports from mapping inputs (contracts/testing-package-resolution.v1.md:3, contracts/testing-package-resolution.v1.md:12, `contracts/testing-package-resolution.v1.md
• proportional-containment: abstain — Established reference-monitor practice requires complete mediation and least-authority local admission: authentication proves publisher identity and byte integrity, but does not authorize publisher-selected executable locations. Parsimony’s claim that verified module, function, and port dispatch is technically sound does not move me because the repository’s normative contract assigns semantic target selection to the Runtime’s closed compatibility registry and expressly excludes dynamic imports and paths from mapping inputs (contracts/testing-package-resolution.v1.md:3, `contracts

⟦AI:FKST⟧

[chronoai-fkst]

github-devloop convergence round 1 - no consensus across angles; narrowing

Narrowed question: publisher-authenticated module, function, and port coordinates versus Runtime-owned semantic authorization + revised issue text limiting verified outputs to identities resolved through contract.testing_package_executor.semantic_mappings, or a superseding normative contract and implementation authorizing publisher-selected coordinates

Angle stances:

• teleology: abstain — Established trusted-update/reference-monitor practice still governs: authentication proves provenance, while local authorization remains a separately mediated Runtime decision. The natural-ownership peer’s caveat that the returned coordinates might merely report resolver-selected values is defeated by the issue’s explicit commands to “Resolve/require and call only the returned module and function,” derive invocation fields from those values, and retain no hardcoded local target. That makes publisher-authenticated coordinates causally authoritative. The normative contract instead as
• parsimony: abstain — Established trusted-update/reference-monitor practice separates publisher authentication from local execution authorization. The root blocker remains: the issue requires executeVerified to load and call publisher-authenticated module and function values and expose the authenticated port, converting signed metadata into executable authority without proving the established practice inapplicable. This contradicts the normative contract: the resolver owns semantic target selection, contract.testing_package_executor.semantic_mappings is the closed compatibility registry, and dynamic impor
• fidelity: abstain — Established trusted-update/reference-monitor practice separates authenticated publisher claims from locally authorized execution under complete mediation and least authority. The root blocker remains explicit: the issue requires executeVerified to “Resolve/require and call only the returned module and function,” expose the returned port, and remove independent executable defaults. This defeats the natural-ownership peer’s weakest alternative that the coordinates might be merely reported: they are expressly made causal dispatch authority. The repository’s normative contract inst
• natural-ownership: abstain — Established trusted-update/reference-monitor practice separates authenticated publisher claims from local execution authorization. The proportional-containment hypothesis that authenticated module, function, and port coordinates may control dispatch is defeated by the normative contract: the resolver owns semantic target selection, contract.testing_package_executor.semantic_mappings is the closed Runtime registry, and dynamic imports are excluded (contracts/testing-package-resolution.v1.md:3, contracts/testing-package-resolution.v1.md:12, `contracts/testing-package-resolution.v1.md
• proportional-containment: abstain — Established trusted-update/reference-monitor practice separates authenticated publisher claims from local execution authorization; complete mediation and least authority require the Runtime to retain semantic selection and capability projection. The root blocker remains: the issue mandates that executeVerified require and call verifier-returned module and function strings and expose its returned port, although the normative contract assigns semantic selection to the resolver, declares contract.testing_package_executor.semantic_mappings the closed Runtime registry, and expressly exclu

⟦AI:FKST⟧

[chronoai-fkst]

github-devloop reconcile action: drop

Reason:
evidence-continuation-budget-exhausted-after-1-rounds

⟦AI:FKST⟧