Programmable Launch Policy v1.11.0

v1.11.0

Programmable Launch Policy replaces the former Submit a Launch repository identity and retires every GitHub
application transport.

• The canonical repository name is 0xprogrammable/launch-policy; numeric repository ID 1320171831 is unchanged.
• docs/builder/intake-status.json and Registry discovery report state: "closed".
• Pull requests that change submissions/ or canary-submissions/ fail closed and point to the Custom Launch API.
• Policy, schema, checker, Registry, documentation, and workflow maintenance continue through ordinary read-only CI.
• Existing application, Canary, release-history, frozen vendor, and old pull-request provenance remains unchanged.
• Current launch preparation uses POST https://api.programmable.market/v1/custom-launches with a Programmable API key.

This release changes the repository front door, not the authority boundary. API preparation, wallet signing, broadcast,
finality, indexing, Registry promotion, and third-party terminal adoption remain separate evidence states.

Submit a Launch v1.10.0

Submit a Launch v1.10.0

Version 1.10.0 makes the current launch contract practical for builders who use Hookbuilder, another agent, or no
agent at all. It preserves the open-world intake: requirements depend on the route and evidence a project actually
selects, not on a fixed list of allowed product ideas.

What changed

• Added a deterministic Application V3.2 scaffold for no-market, external, unresolved, and official Programmable
  Ethereum routes. The scaffold never invents source, trade, fee, Router, deployment, stamp, or settlement evidence.
• Clarified the public agent and pull-request guidance so self-built projects and third-party tools follow the same
  canonical contracts and policy as Hookbuilder-generated projects.
• Added a production-only runtime fee-settlement requirement alongside the existing prelaunch 10 bps commitment and
  finalized Router-stamp requirement.
• Kept repository-side settlement assertions deliberately analysis-pending. They cannot mint a passed observer
  proof or claim that runtime collection, finality, settlement, future payment, or ongoing monitoring was verified.
• Extended Active Contract V2 so agents can discover the scaffold and the complete settlement-assertion validation
  closure from one integrity-bound contract.
• Updated launch-stamp promotion receipts to bind the current Policy 2.1.0 readiness decision while preserving the
  exact accepted Application V3 package and finalized Router evidence.

Authority and compatibility boundary

Application V3.1 remains byte-unchanged legacy compatibility. Application V3.2 remains the current contract for an
official Programmable Ethereum route. A scaffold is only a local draft helper; it does not submit, approve, deploy,
sign, broadcast, classify, promote, or authorize funds.

The enabled launch-readiness profile remains checker-only. The production-launch profile remains disabled. The
new runtime settlement contract documents and structurally validates a pending assertion, but a future independently
anchored observer verifier is still required before that production-only rule can pass.

Verify locally

Use Node.js 24.12 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.9.0

Submit a Launch v1.9.0

Version 1.9.0 publishes the complete, open-world Application V3.2 contract for launch submissions while preserving
the byte-unchanged Application V3.1 compatibility path. Requirements remain conditional on the route a project
actually selects; unfamiliar project types and no-market designs are not excluded by a capability allowlist.

What changed

• Added Application V3.2, Submission 2.1, and the policy-neutral Trade Capability Manifest V2 as the complete current
  application package for the official Programmable route.
• Added the checker-only launch-readiness profile and an offline, closed Router-readiness document that binds the
  exact reviewed source, route components, manifest-resolved canonical Router, and fee plan.
• Made the selected Programmable Ethereum-mainnet route require exactly 10 bps (0.10%) of gross canonical-pool
  trading volume for the Programmable treasury at 0x4957f49620AFf3Adbbe8195a4f633E49cc93376c.
• Required the atomic canonical Router path for Programmable provenance. Direct Classic Factory, Graph Factory, or
  Single Factory calls do not create a canonical Programmable classification.
• Added the maintainer-owned, finalized launch-stamp promotion contract. A promotion receipt carries the full passed
  launch-readiness decision, exact readiness bytes, application and package bindings, and the closed finalized Router
  evidence needed before Registry, API, indexer, or public terminal classification.
• Published Applicant Compatibility V2 for discovery of the V3.2 package and its supporting contracts while retaining
  Applicant Compatibility V1 and Application V3.1 as legacy compatibility surfaces.

Authority and compatibility boundary

Application V3.1 remains accepted under its unchanged compatibility contract, but it cannot establish
launch-readiness or the official Programmable Router route. An official-route project must add a new V3.2 revision;
existing V3.1 bytes are not reinterpreted or rewritten.

The enabled launch-readiness profile is checker-only and returns
LAUNCH_READINESS_CHECKED_NOT_AUTHORIZED. The production-launch profile remains disabled. No source validation,
readiness result, receipt, tag, or GitHub release grants signing, deployment, public routing, production discovery,
real-user funds, audit, safety, liquidity, sellability, or launch authority.

The authenticated Universal Admission queue and its SQLite backend remain reference-only-disabled: there is no
public queue endpoint, audience, or worker plane. Publishing a valid finalized promotion receipt makes deterministic
terminal integration possible, but does not guarantee adoption by any third-party terminal, provider, indexer, or UI.

Verify locally

Use Node.js 24.12 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.8.0

Submit a Launch v1.8.0

Version 1.8.0 adds Universal Admission V1 as one project-agnostic Applicant admission protocol for hooks, tokens,
apps, games, services, hybrids, no-market projects, and novel designs without a project-type or capability allowlist.

What changed

• Added one bounded public Submission V2 admission envelope that preserves unknown capabilities as analysis-pending
  instead of rejecting a project because its category is unfamiliar.
• Separated semantic admission from transport authentication, replay protection, quotas, leases, fencing, retry,
  dead-letter retention, snapshots, and garbage collection.
• Added authenticated command and event receipts plus an owner-private, single-host SQLite reference implementation
  with store-conformance, recovery, integrity, and adversarial tests.
• Published an exact, digest-bound Universal Admission discovery contract covering the closed schemas and reference
  runtime while keeping the existing Application V3.1 GitHub Draft intake and launch policy unchanged.
• Documented that launch-route requirements, including the disabled Programmable production profile, are not universal
  Applicant admission requirements.

Authority boundary

The Universal Admission contract remains reference-only-disabled: its endpoint, audience, and trust snapshot are
unset; every authority flag is false; and the SQLite adapter is not a distributed production service. Admission does
not grant review, acceptance, approval, audit, deployment, discovery, routing, funds, safety, or launch authority.

Verify locally

Use Node.js 24.12 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.7.0

Submit a Launch v1.7.0

Version 1.7.0 adds a closed compatibility contract for protected Applicant intake and a compact, receipt-bound
validator package generated from the exact released Hookbuilder v0.11.0 Skill tree.

What changed

• Publish an exact-base compatibility manifest for Application V3.1 schema, capability, repository, protocol, and
  compact validator bindings.
• Verify every compact package file, byte length, SHA-256 digest, and the complete closure before importing its
  public Applicant validator facade.
• Use the compact facade throughout protected Application V3.1 intake while preserving the released Hookbuilder
  v0.10.3 full-vendor package as the exact compatibility-less legacy fallback.
• Keep the compact package inert during binding verification and reject substitution, unknown capabilities, wrong
  repository identity, and unsupported Builder protocol versions.

Authority boundary

The compatibility contract enables only normal unreviewed Applicant Draft transport. It does not grant review,
acceptance, approval, deployment, discovery, routing, funds, or launch authority. Candidate code remains inert under
protected-base validation.

Verify locally

Use Node.js 24 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.6.3

Submit a Launch v1.6.3

Version 1.6.3 updates the protected Application V3.1 source resolver to the exact released Hookbuilder v0.10.3 skill
tree and fixes missing manifest source blobs during trusted intake.

What changed

• Fetch every tree-derived blob object ID in one bounded anonymous Git batch.
• Stop relying on sparse backfill reporting success before all declared blob objects are locally readable.
• Keep exact repository ID, public URI, commit, tree, path, mode, blob object ID, file-size, and package bindings.
• Preserve the existing file-count, byte, process, timeout, and temporary-storage limits.
• Keep candidate code, Git hooks, filters, submodules, and workflows inert under protected-base validation.

Authority boundary

This patch changes only trusted source retrieval. A valid Application V3.1 package remains an unreviewed Applicant
Draft. It does not grant review, acceptance, approval, deployment, discovery, routing, funds, or launch authority.

Verify locally

Use Node.js 24 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.6.2

Submit a Launch v1.6.2

Version 1.6.2 fixes the protected Application V3.1 source resolver for valid inline source closures that also identify
their contract files as an explicit subset.

What changed

• Project overlapping sourcePaths and contractPaths once into the disjoint trusted GitHub source request.
• Preserve the complete remotely verified path union and the original Application source closure.
• Continue rejecting any contract path outside the exact source closure before remote resolution.
• Keep repository ID, public repository URI, commit, tree, source artifacts, and package bytes exactly bound.

Authority boundary

This patch changes only source verification transport. A valid Application V3.1 package remains an unreviewed Applicant
Draft. It does not grant review, acceptance, approval, deployment, discovery, routing, funds, or launch authority.
Candidate repository content remains inert data under the protected-base validator.

Verify locally

Use Node.js 24 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.6.1

Version 1.6.1 lets a semantically valid custom Submission V2 at stage: proposal enter the protected Application
V3.1 Draft intake when legacy Fee V2 is explicitly not-selected.

What changed

• Accepted policy-neutral proposal packages only when their compatibility report remains
  architecture-review-required.
• Preserved the exact all-null legacy Fee V2 tuple for not-selected submissions.
• Rejected proposal packages that fabricate a trade-capability manifest, trade-test result, prototype readiness, or a
  mismatched Application stage.
• Kept the existing prototype and selected legacy Fee V2 paths unchanged.

Authority boundary

A valid proposal package creates only an unreviewed Applicant Draft eligible for independent review. It does not prove
prototype readiness, trade capability, testing, audit, deployment, availability, approval, or launch authorization.
Candidate repository content remains inert data under the protected-base validator.

Verify locally

Use Node.js 24 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.6.0

Version 1.6.0 adds the generic Application V3.1 protected draft intake. Complete no-market, tradable, hook, token,
app, game, service, and hybrid projects can use one project-agnostic contract without a project-type or capability
allowlist.

What changed

• Added the central public-pr-application-v3 contract version 3.1.0 and its closed JSON Schema.
• Added add-only revision packages under
  submissions/<application-id>/v3/revisions/<positive-decimal-revision>/.
• Added protected-base validation for bounded canonical data, exact Git and applicant identity, immutable lineage,
  source closure, evidence bindings, package digests, and public-data safety without executing applicant code.
• Preserved novel capability evidence through pinned source records and additional review records instead of filtering
  projects through a category allowlist.
• Made legacy Fee V2 bindings conditional. Projects that did not select Fee V2 use the explicit not-selected state
  and an all-null fee tuple without fabricated fee artifacts.

Compatibility and authority

Legacy V2 and hidden Workflow Canary intake remain separate supported transports. V3.1 does not rewrite their bytes,
move their pull requests, inherit their status, or satisfy Canary or Website eligibility.

A valid V3.1 package is only an official draft eligible for review. Validation does not mean the project has been
reviewed, accepted, approved, audited, deployed, listed, made available, launched, or authorized to handle funds.
Registry promotion and every production fact remain separately evidenced maintainer actions.

Verify locally

Use Node.js 24 or newer:

npm ci --ignore-scripts
npm test

Submit a Launch v1.5.0

Version 1.5.0 makes the repository-owned launch policy the single authored source for Programmable-specific admission
requirements. The policy, reviewer, Workflow Canary, generated documentation, and integrity checks now bind the same
exact policy identity and stable Rule IDs.

What changed

• Added the canonical policy/launch-policy.v1.json contract and generated, digest-bound public projections.
• Added a policy-bound deterministic reviewer that cannot accept private analyzer requirements.
• Added the one-file hidden Workflow Canary for testing the GitHub application handoff without creating a launch,
  Registry entry, audit claim, public route, or permission to use real funds.
• Added primitives for short-lived, signed, audience-bound hidden Canary eligibility. The repository does not claim that
  a Website signer, replay or revocation service, or production Website integration has been deployed.
• Added a repository ownership manifest that closes the reviewed file inventory, admission entrypoints, import graph,
  Rule-ID handlers, generated projections, and frozen vendor boundary.
• Added a release integrity gate that requires package.json, the root lockfile projections, Registry config, and the
  current history snapshot to agree on version 1.5.0 and verifies every released Registry history snapshot by exact
  bytes.
• Added the append-only Registry history snapshot for 1.5.0. Project records and their Registry digest are unchanged.

Compatibility and authority

The receipt-bound Hookbuilder v0.5.1 validator and existing six-file legacy V2 intake remain unchanged compatibility
paths. They do not satisfy Workflow Canary, hidden Website eligibility, or production launch authority.

The canonical policy remains version 1.1 and existing v1 schemas retain their versions. The production-launch
profile remains disabled, and this release cannot emit LAUNCH_APPROVED. Passing checks is not an audit, deployment,
public availability, funds authorization, or launch approval.

Verify locally

Use Node.js 24 or newer:

npm ci --ignore-scripts
npm test