gabriel / muse public
Open #108 Enhancement
filed by aaronrene human · 27 days ago

Design: safe independently owned executable domain plugins

0 Anchors
— Blast radius
— Churn 30d
0 Proposals

Safe external Muse domains — master plan and approval proposal

Status: Proposal for Gabriel's design review. No implementation is authorized by this document.

Proposed issue title: Design: safe independently owned executable domain plugins

Plain-language plan

The problem

Muse can only run domains that are compiled into Muse's own Python package and listed in its internal registry. MuseHub lets people publish domain descriptions, but those marketplace entries are metadata; they are not independently installable domain engines.

That leaves VideoFactory, Knowtation, and future domain owners with two bad choices: fork Muse or wait for every domain to be merged into Muse core. It also means that simply adding package discovery would create a new risk: untrusted Python would run with the user's files, credentials, environment, and network access.

The recommendation

Add independently released domain packages, but run external domain logic through a small, isolated WebAssembly interface. Keep existing built-in Python domains working as they do today. MuseHub distributes and describes external packages in the first release, but does not execute them on its servers.

Every executable release is:

  • explicitly installed and removed by the user;
  • signed by its publisher;
  • selected by its exact package SHA-256, never only by a version name;
  • bound into signed Muse repository history;
  • denied ambient access to files, keys, environment variables, and networking; and
  • safe to preserve, clone, fetch, push, and view when the package is unavailable.

A repository may say which package it requires. It may not install, trust, or execute that package automatically.

The smallest safe first release

The first release should support one external runtime and a narrow set of domain operations: snapshot, diff, merge, validate, and explicit migration. It should add:

  1. Immutable signed package releases in MuseHub, including private releases.
  2. Explicit local install, activation, upgrade, and removal in Muse.
  3. An exact plugin identity/version/digest binding in new signed commit history.
  4. A WebAssembly worker with no filesystem, environment, clock, randomness, process, or network access unless a later interface grants a specific capability.
  5. Generic MuseHub history and file viewing without server-side package execution.
  6. Fail-closed behavior for missing, revoked, incompatible, or incorrectly pinned packages.
  7. Client-computed, signed merge commits for external domains; MuseHub only validates and advances the ref in this release.

Do not include automatic installation, automatic upgrades, Python entry-point execution, arbitrary package CLI commands, executable web viewers, or server-side external plugin execution in the first release.

What approval is requested

Gabriel is asked to approve the platform direction and ownership boundaries, not a finished implementation:

  • external executable domains may be independently owned and released;
  • WebAssembly plus a narrow capability interface is the initial external runtime;
  • existing Python domains remain supported built-ins;
  • package identity is cryptographically bound into new history;
  • MuseHub remains a non-executing registry/viewer in the first release;
  • Aaron may lead a reference implementation using VideoFactory and/or Knowtation;
  • implementation is split into separately reviewable Muse and MuseHub issues after the contract is frozen.

AWS access is not the deciding authority for this design. Aaron's collaborator access is sufficient to write the proposal, open the issue, build a feature branch, and submit a merge proposal. Gabriel's approval is needed because the design changes Muse's plugin trust boundary, commit/wire compatibility, and MuseHub's package and organization authorization model.

Proposed sequence

  1. Approve or amend this design issue.
  2. Freeze a small cross-repository contract: package descriptor, signing payload, domain binding, execution ABI, compatibility rules, and refusal behavior.
  3. Open implementation sub-issues in Muse and MuseHub with red tests and exit gates.
  4. Build one metadata-focused reference package from an independently owned source repository and install the built artifact in a clean environment.
  5. Run isolation, determinism, compatibility, private-access, revocation, and rollback tests before enabling new-format writes.
  6. Pilot on staging with opt-in users. Production remains disabled until the pilot passes and rollback has been exercised.

Useful work while approval is pending

We can prepare the evidence and test materials that make the eventual decision and implementation faster. This work must not create an external executable package, register a domain, modify Muse/MuseHub behavior, change .muse/repo.json, or use AWS to publish or deploy anything.

Preparation Owner Deliverable Why it is safe now
Freeze the current-state evidence Aaron A short compatibility ledger for the active Muse release, workspace checkout, built-in registry, wire format, and MuseHub marketplace model Records facts without changing them
Define two reference corpora Aaron with domain owners A small redacted Knowtation vault and a small synthetic VideoFactory source-layer timeline, each with expected snapshot/diff/merge/refusal outcomes Establishes acceptance tests without choosing a runtime or shipping code
Write the external-domain conformance suite specification Aaron Input/output schema examples, determinism fixtures, isolation probes, migration cases, and failure expectations Makes the approval decision testable before implementation
Map package authority and privacy needs Aaron and Gabriel Publisher identities, required private-package readers, organization/delegation needs, key-rotation expectations, and revocation policy questions Identifies policy decisions without granting access or creating credentials
Produce a release/custody inventory Aaron Proposed source owner, license/notice inventory, reproducible-build requirements, artifact retention, and rollback requirements for each reference domain Keeps domain ownership clear before a package exists
Break implementation into reviewable tickets Aaron Draft Muse, MuseHub, reference-plugin, and staging-qualification issue outlines, kept unpublished until the contract is approved Makes scope and ownership visible without committing the team to a design

The two highest-value tasks are the reference corpora and the conformance-suite specification. They turn the discussion from "which plugin framework sounds right?" into "which design correctly handles these known domain behaviors and failures?"

Decision-gated roadmap

Gate / phase Scope Exit result
0 — Prepare now The six preparation deliverables above; no executable artifacts or platform changes Gabriel has concise evidence, fixtures, policy questions, and a testable contract proposal
A — Design approval Resolve the seven approval questions in this issue and name the initial reference domain(s) A recorded decision on runtime, history binding, MuseHub posture, ownership, and private-package policy
1 — Contract freeze Specify the release descriptor, canonical signing payload, binding record, ABI, feature negotiation, and refusal behavior Versioned interface documents and golden test vectors approved for implementation
2 — Readers and safeguards MuseHub storage/read paths, generic UI, critical-field preservation, and server merge guards; Muse readers and diagnostics New histories can be safely recognized before any client creates them
3 — Local execution pilot Explicit install/remove/use lifecycle, isolated runner, exact package pins, and one reference package Built artifact passes conformance, isolation, and deterministic-repeat tests locally
4 — Staging collaboration Private/public registry path, clone/fetch/push collaboration, revocation, mixed-version refusal, and rollback exercise Opt-in staging pilot has a written success and rollback record
5 — Broader release Self-service public-unverified releases and digest-specific verification policy Gabriel approves a separate production plan; server-side processing remains out of scope

Current coordination and next prompts

The preparation work has one owner per active lane so the teams do not create competing executable-domain implementations while the decision is pending.

Lane Current next action Boundary
Muse #108a compatibility and conformance preparation, in muse-fresh/docs/MUSE-OVERSEER-HANDOVER.md Documentation and test inputs only; no runtime, history, wire, or installer change
VideoFactory Movie Maker MK2-D1P-a reference-corpus and custody preparation, in MOVIE_OVERSEER_HANDOVER.md No video_timeline package, shared-core branch, catalog listing, or release
Knowtation Continue its already-active L01a-E2-W4-C14 privacy work Its next handoff is unchanged; it contributes a redacted reference corpus only when that work can be scheduled without interrupting the privacy gate

The first review should use the two preparation outputs to decide whether the contract handles real domain state and failure modes. It should not treat an existing declarative catalog listing, an old core-plugin proposal, or a clean checkout as approval to build an executable package.

Technical plan

1. Separate the domain classifications

Identity, visibility, review status, and executability are independent fields.

Class Meaning Execution rule
Built-in Ships inside an authenticated Muse release Existing Python implementation remains supported
Verified public Public executable release with a publisher signature and digest-specific review attestation Explicit install; same sandbox as every external package
Public unverified Public, publisher-signed release without the review attestation Explicit install; organization policy may forbid it
Private Release and metadata protected by user/org grants Same signature, digest, and sandbox requirements
Metadata-only Declarative marketplace listing and curated viewer configuration Never supplies executable VCS behavior

Private does not mean trusted. Verified does not mean future versions inherit trust. Publisher authentication, platform review, and semantic correctness are distinct claims.

2. Immutable package releases and publisher signatures

Keep the current mutable marketplace catalog as discovery metadata. Add immutable release objects containing:

  • registry authority, stable publisher ID, and stable plugin ID;
  • human version plus exact package SHA-256;
  • manifest, schema, dependency/resource, and configuration digests;
  • supported Muse plugin ABI and state-schema versions;
  • execution-profile identifier and requested capabilities;
  • publisher key ID and authorization/delegation evidence; and
  • optional digest-specific platform review attestation.

The publisher signs a canonical, domain-separated release descriptor such as MUSE-DOMAIN-RELEASE/v1. The signature is detached from the package so the package digest is not circular. A version coordinate is immutable: publishing different bytes under an existing coordinate is rejected.

Installation verifies both that the downloaded bytes match the signed descriptor and that the signing key was authorized for that stable plugin identity. Signed update metadata must also prevent rollback, freeze, and mix-and-match attacks; use an established TUF-style model rather than treating one package signature as the entire update system.

3. Explicit lifecycle

Proposed interface names, subject to CLI review:

muse plugins inspect <release>
muse plugins install <release> --digest sha256:...
muse domain use <installed-release>
muse plugins remove <release>

Install downloads, verifies, and atomically places a package in a digest-addressed store. It executes no guest code and changes no repository history. Activation is a separate repository action. Approval for one digest never approves another digest.

Clone, fetch, pull, generic viewing, and opening a repository never install or execute a package. Removal disables execution while retaining history and its signed binding.

4. Bind the plugin into signed history

Introduce a negotiated commit/wire format that includes a content-addressed domain_binding_id. The binding contains:

  • stable publisher and plugin IDs;
  • exact version and package digest;
  • signed release-descriptor digest;
  • Muse plugin ABI and state-schema version;
  • deterministic execution-profile identifier; and
  • semantic configuration digest.

Include the commit format and domain_binding_id in the canonical commit identity. The author's existing commit signature then binds the package selection transitively. A local lock file may cache this information but cannot override signed history.

Add a content-addressed operation record for plugin-produced results. It binds the operation, inputs, ordered merge roles, output snapshot, and structured-delta or migration-evidence digest. If a structured delta is not bound, label it as derived presentation data rather than authenticated history.

Once a history opts into bound external domains, later omission of the binding is a downgrade attempt and must be rejected. Plugin upgrades and rollbacks are explicit signed transitions, with a migration when state schemas differ.

The current wire reader ignores unknown commit fields. Therefore this change requires feature negotiation and exact preservation in local storage, server ingestion, database indexing, fetch reconstruction, and repair before new clients may write the format. An old peer must refuse a critical format it cannot preserve.

5. External execution boundary

Do not expose the existing filesystem-oriented Python plugin protocol directly to third parties. Muse's trusted host owns file selection, ignore rules, object access, path validation, working-tree mutation, repository transactions, and signing.

The external ABI should behave like pure operations over bounded data:

snapshot(inputs, configuration) -> state description
diff(base, target, configuration) -> delta
merge(base, ours, theirs, configuration) -> candidate + conflicts
validate(candidate, configuration) -> findings
migrate(source, target_schema, configuration) -> candidate + report

The first WebAssembly profile grants no filesystem preopens, environment variables, networking, DNS, sockets, clocks, randomness, process execution, or dynamic module loading. Run each job in a fresh trusted worker process with explicit IPC handles and limits on package size, compilation, memory, stack, tables, fuel, elapsed time, host calls, inputs, outputs, and diagnostics.

Object reads are capabilities for an explicit job input set, not general reads by digest. Otherwise a plugin could probe unrelated data in a shared object store. Signing keys, credential-agent sockets, registry credentials, and administrative files remain outside the worker. Muse validates all returned paths, references, counts, and operations, then stages a recoverable transaction and signs only after validation.

WASM is the primary capability boundary; the worker process adds crash containment. Use OS confinement where supported. A plain Python subprocess under the user's account is not a sufficient sandbox. A later native-plugin profile could use stronger OS or VM isolation, but it must never fall back silently to an unrestricted subprocess.

6. Deterministic domain behavior

The complete inputs to an operation are the package digest, execution profile, configuration digest, operation kind, ordered input identities, and immutable input bytes. Specify canonical encoding, duplicate-key rejection, path rules, ordering, Unicode treatment, integer/rational representation, and output limits.

  • Snapshot preserves complete retrievable state; semantic projections do not replace raw content identity.
  • Applying an accepted diff reproduces the target state.
  • Merge has explicit base/ours/theirs roles, stable conflict ordering, and full-result validation. Unsupported semantics conflict or refuse.
  • Migration declares exact source and target bindings, previews changes, creates a new signed commit, and leaves original objects unchanged.
  • Checkout restores recorded bytes through trusted core code; untrusted post-checkout hooks cannot mutate arbitrary paths.

Do not grant nondeterministic host imports. Configure floating-point behavior where needed and exclude nondeterministic runtime features. Require repeatability on all supported platforms and runner builds. Do not assert commutativity or associativity unless the domain declares and proves those properties.

7. Private packages and organization permissions

Separate repository read/write permissions from package permissions:

Package permission Authority
Read Discover private metadata and download authorized artifacts
Publish Create immutable releases for a delegated publisher identity
Administer Manage grants, delegates, visibility, and policy
Revoke Publish authenticated security revocations
Verify Issue platform review attestations; separate from ownership

Organization membership feeds explicit package grants. Repository write access does not imply package publication authority, and repository membership does not automatically expose all private packages.

Use authenticated, scoped, short-lived artifact access. Apply authorization to metadata, downloads, caches, search, logs, and deduplication responses. Knowing a digest is not access. Credentials and signed URLs never enter repository history or the worker environment.

Before org membership becomes package authority, review and test creator-bound, race-safe bootstrap and the zero-member state. Revocation prevents future authorized downloads and execution under managed policy; it cannot erase bytes already obtained.

8. Compatibility and refusal behavior

Condition Required behavior
Package missing or removed Preserve, clone, fetch, push, verify, generically inspect, and explicitly restore raw bytes; block semantic operations
Wrong version or digest Show required and installed identities; refuse rather than substitute
Revoked package/key Preserve history and generic reading; disable execution; reject new use on protected refs
Stale revocation metadata Preserve reading; refuse new activation or policy-sensitive writes until refreshed
Unsupported ABI/schema Preserve opaque supported storage; refuse interpretation, merge, and migration
Unsupported critical commit/wire format Refuse the operation; never discard the field

Clone and fetch never execute packages. Push verifies objects, signatures, bindings, graph completeness, permissions, and branch policy without loading an external package. Collaborators use the exact binding selected by each commit. Branches with different bindings require an explicit compatible transition or migration before a semantic merge.

9. MuseHub without server-side execution

MuseHub can show commit graphs, signatures, bindings, release/review status, file trees, bounded text/JSON and byte diffs, downloads, client-produced signed summaries, and fixed curated viewers driven by declarative configuration.

It does not accept package JavaScript, HTML, server-side WASM, remote schemas, or URLs that it automatically fetches. External-domain server merges, squash, cherry-pick, semantic indexing, and history rewrites refuse unless their behavior is explicitly safe without plugin interpretation.

For the first release, an authorized client computes and reviews a semantic merge, signs the resulting commit, and pushes it. MuseHub verifies the envelope and advances the ref only if the expected previous head still matches. The UI must distinguish history-integrity verification from semantic validation.

10. Future server processing

Reuse the same ABI in disposable tenant-isolated workers outside the web/API process. The scheduler authorizes an exact operation, package digest, input IDs, configuration, and budget. A broker supplies only those inputs. Workers receive no database, object store, registry, or signing credentials and no network access.

Begin with disposable indexes and previews. Validate results outside the worker and record a separate execution attestation. That attestation never impersonates the repository author. History-producing server operations require a later design review and explicit product policy.

11. Backward compatibility

Old commit IDs, signatures, snapshot formulas, and built-in repositories remain valid. Existing built-ins use a legacy adapter until they opt into the new binding format. Do not claim retroactively that old commits identify an exact implementation when they did not record one.

Reserve built-in identifiers so an external package cannot shadow a built-in through its name, import path, or search order. Capture compatibility fixtures from supported Muse releases because the installed and workspace registries can differ.

12. Ownership

Area Muse MuseHub Design approval
Package identity and local trust Resolver, trust policy, lifecycle Immutable registry and attestations Gabriel approves shared contract
External ABI and isolation Broker, worker, validators, SDK No execution in v1 Gabriel approves trust-boundary change
Signed binding and operation record Hashing, signing, local storage Ingest, persistence, serving, verification Gabriel approves format compatibility
Private/org packages Credential handling and local policy ACLs, delegated publication, audit Gabriel approves authorization semantics
Generic collaboration Produce bound client results Viewers, labels, guarded ref updates Gabriel approves server trust claims
Domain algorithms Independently owned packages Distribution under policy VideoFactory/Knowtation owner
Server-side workers Shared ABI and conformance Separate worker service Separate future approval

Aaron can lead the proposal, reference package, Muse and MuseHub feature branches, and staging qualification through the normal issue/merge-proposal process. Gabriel may choose to lead any platform work, but the design does not require him to be the sole implementer. Production enablement and merges into protected branches remain subject to the existing review and operational gates.

13. Threat model and release-gating tests

Assume malicious packages, malicious repository contributors, compromised publisher keys, tampered or stale registries, hostile files, false client execution claims, and resource-exhaustion attempts. Protect signing authority, private data and packages, history integrity, unrelated files, and service availability.

Required test groups:

  • package/signature substitution, dependency confusion, delegated-key rotation, rollback, freeze, and mix-and-match metadata;
  • archive traversal, symlinks, duplicates, decompression bombs, install hooks, and code execution during inspection or installation;
  • canary signing material, unrelated files/objects, environment secrets, credential sockets, DNS, TCP/UDP, loopback, local sockets, and cloud metadata access;
  • binding, configuration, schema, operation-record, merge-role, migration-record, and wire-format tampering;
  • deterministic cross-process/platform fixtures, lossless snapshot/restore, diff/apply equivalence, domain merge properties, conflict preservation, and migration completeness;
  • old peers, stripped fields, mixed bindings, legacy-to-bound transitions, and exact client/server commit-ID parity;
  • cross-org private access, removed delegates, empty-org bootstrap races, digest enumeration, and stale authorization;
  • infinite loops, memory/output growth, host-call floods, crashes, and interruption at every install and repository transaction boundary; and
  • hostile HTML, Markdown, SVG, URLs, terminal escapes, and forged verification labels in generic viewers.

14. Rollout and rollback

  1. Contract: approve/freeze the descriptor, ABI, history binding, compatibility, permissions, and refusal behavior. Build throwaway VideoFactory/Knowtation pilots.
  2. Readers first: deploy immutable release storage, ACLs, protocol readers, generic UI, and server merge guards while new-format writing stays disabled.
  3. Opt-in staging pilot: enable one public and one private external package; test the complete lifecycle and rollback from built artifacts.
  4. Public distribution: allow self-service public-unverified releases under the same sandbox; add verified digest attestations and organization policies.
  5. Server workers later: begin only with disposable derived results after a separate isolation and product review.

Maintain separate kill switches for publishing, downloading, new installation, execution, and new-format writes. During an incident, generic reading and compatible object transport remain available. Keep immutable artifacts, descriptors, revocation history, and additive database fields. Never roll MuseHub back to a version that silently drops critical bindings.

A plugin rollback is a signed transition to an allowed prior digest, plus an explicit reverse migration or restored state when necessary. It does not overwrite release bytes, rewrite history, revive revoked packages, or run an old executable against an unsupported newer schema.

Proposed approval checklist

Gabriel can approve the direction by answering these seven points in the issue:

  1. Approve independently owned executable domains without Muse forks?
  2. Approve WebAssembly/capability execution as the external v1 runtime?
  3. Approve exact package identity in a new signed commit/wire format?
  4. Approve non-executing MuseHub behavior and client-produced semantic merges for v1?
  5. Approve immutable public/private releases with separate publisher and review trust?
  6. Approve Aaron leading a reference package and cross-repository implementation plan?
  7. What changes, if any, are required before this contract can be frozen?

Approval authorizes implementation planning and sub-issues. It does not authorize production deployment or arbitrary third-party server execution.

Issue placement

Create the master design issue in gabriel/muse, because the decisive trust boundary, plugin ABI, signed history, and compatibility changes live in Muse. After approval, create linked implementation issues in both gabriel/muse and gabriel/musehub.

Related work to reference rather than repurpose:

The MuseHub issue intentionally delivered declarative marketplace domains and excluded third-party executable plugins. The domain-specific issues should retain their product history. This master issue supplies the missing platform contract they can depend on.

◎ Activity6
●
aaronrene opened this issue 27 days ago
○
aaronrene 24 days ago

The requested WebAssembly interface prototype review is ready:

Muse #108 WebAssembly interface prototype review

The review document is attached to this issue as Muse commit sha256:82cff775455e411f716d311ca9a8a720eb27269ffc6b9fa6cf4a87ec5e116e63. Its whole-file SHA-256 is 8b517a8c263c8b0ff536bf3079d332c6b432198c72836d4574d7236fae5bbbfe.

The prototype shows a wasm32-unknown-unknown linear-memory interface with no host imports and five domain operations: validate, snapshot, diff, merge, and migrate. The document includes the export table, buffer/configuration rules, refusal classes, limits, demonstration evidence, production-isolation gaps, and proposed next gates.

Nothing has been packaged, signed, installed, registered, uploaded, or deployed. No VideoFactory source or executable module was copied into Muse. MuseHub remains non-executing.

Please confirm or redirect the five decisions under Decisions requested from Gabriel, particularly:

  1. raw linear-memory ABI versus WIT/component model;
  2. whether the vt_* names should become the real versioned ABI;
  3. the exact five first-release operations;
  4. MuseHub's non-executing v1 posture; and
  5. authorization to freeze and independently review the remaining package/signing/history/lifecycle contract.

Confirmation authorizes the documents-only contract freeze. It does not authorize a package, signature, installation, catalog entry, deployment, or production change.

○
gabriel 19 days ago

Thanks for the thoroughness here — both the master design and the WASM prototype review are exactly the kind of evidence-first work I want to see before committing to a platform trust-boundary change. Going through the master checklist and then the five prototype decisions.

Master issue — the seven approval points

  1. Independently owned executable domains without a Muse fork — approved. The problem statement is right: forking or waiting for core merges doesn't scale past two external domains, let alone more.
  2. WebAssembly + capability execution as the v1 external runtime — approved. Right answer for "run untrusted logic without ambient access to files, keys, env, or network." MuseHub staying non-executing in v1 removes the scariest failure mode (server-side RCE via a malicious plugin) entirely — no notes, keep that as a hard line, not a nice-to-have.
  3. Exact package identity in a new signed commit/wire format — approved to spec, not to ship. This is the highest-blast-radius piece in the whole document — it touches canonical commit ID computation for every future commit on an external-domain repo. Before I call this frozen, I want a working spike against a real existing repo's history proving the migration path, old-peer refusal, and mixed-version interop actually hold up in practice, not just on paper. We've been burned before by schema changes that looked simple in the design doc and weren't once real history was involved — I'd rather find that out in a spike than in production.
  4. Non-executing MuseHub + client-produced signed merges for v1 — approved. Correct scope for a first release.
  5. Immutable public/private releases with separated publisher/review trust — approved in direction, with a request: can v1's pilot (Gate 4) run with just single-publisher signed packages and skip org delegation + the verified/unverified split entirely? Five package roles × org delegation × five domain-visibility classes is a lot of identity/access-control surface to get right on the first pass. If the pilot doesn't need it, let's not build it until it does.
  6. Aaron leading a reference implementation — approved, scoped to exactly what's in the doc (reference package, feature branches, staging qualification through the normal review process). Production enablement and protected-branch merges stay under the existing gates, same as anyone else's work.
  7. Changes required before contract freeze: see the two asks below — the drift/apply/schema confirmation, and evidence-artifact access for the prototype.

Prototype review — the five decisions

  1. Raw linear memory vs. WIT/component model: keep raw linear memory + length-delimited JSON envelopes for v1. It's already proven end-to-end in this exact prototype, and it matches how the rest of Muse talks over the wire everywhere else (stage index, commit records, domain-info --json, MSign payloads — plain JSON, not a typed IDL). Let's not introduce a stylistically different convention for one subsystem. Design the package descriptor's ABI-version field so a v2 component-model variant can sit alongside this later if a future domain actually needs it.
  2. vt_* export names: don't carry these into the real ABI — rename to something domain-neutral before this becomes the contract every future external package implements. vt is VideoFactory's own abbreviation; it shouldn't leak into the platform-wide convention.
  3. Exactly validate/snapshot/diff/merge/migrate, no guest apply/drift/schema — approved, with one thing to confirm first. The reasoning holds (schema is static metadata, apply is host-side bytes-to-disk, drift composes from snapshot+diff), but muse status is the single most frequently run command in the CLI, and the doc's own "what remains" list still has an open item for worker-process lifecycle. Before this is final: what's the measured per-call overhead of vt_snapshot + vt_diff back-to-back through a fresh instance? If that's not fast enough for interactive status, we need to know now, not after it's load-bearing.
  4. MuseHub stores/indexes/authorizes/serves but never instantiates or executes — approved, consistent with the master issue's point 4.
  5. Authorize a documents-only contract freeze — approved. This is genuinely low-cost: no package, signature, install, catalog entry, or deployment is authorized by saying yes here, and every later gate gets its own separate review per the doc's own gated path.

One condition on the evidence itself

The four evidence pins (freeze, independent review, demonstration record, build verification) are hashes of artifacts currently in VideoFactory custody — I can't see the actual module, fixtures, or build logs behind them yet. For a proposal whose whole thesis is "don't trust external code you can't verify," I'd like those artifacts actually shared for independent review before any later gate treats this prototype's isolation properties as settled. Not blocking the documents-only freeze on this, but it needs to happen before Gate 2.

Go ahead and start the contract-freeze spec. Loop me in on the commit-ID migration spike and the status-latency numbers before either gets called final.

○
aaronrene 14 days ago

Muse #108 — Gate 1 owner decisions requested

Candidate 2 remains UNFROZEN. Its bounded transport and contextual resource corrections passed independent review and are not being reopened. Its overall review remains FAIL for contract freeze because required owner decisions and real-system evidence are absent. No owner decision was obtained during Gate 1d. Candidate 3 is absent.

Please provide structured written replies for R1, S1, P1, H1, H2, L1, B2 and V1 below. Every recommendation is UNAPPROVED. Silence, local artifacts and recommendations are not approval. An explicit deferral leaves an OPEN blocker; it is not a waiver or freeze approval.

This comment requests decisions and identification of existing evidence only. It authorizes no implementation, artifact generation, signing, packaging, installation, activation, registration, upload, deployment, production change, new-format writes, history repair or Gate 2 work. Do not generate missing evidence or carry out a recommendation under this request; record unavailable evidence and its owner/gate instead. H3 and B1 are BLOCKED / NOT RUN and will not start until their prerequisites exist and the execution work is separately authorized.

Decision target and existing authority

Candidate: docs/contracts/external-domain/v1-candidate-2/. Exact candidate-manifest SHA-256: 0169befe5fb7afbce52505c7ecda855567be47ce0e27517e00f247c67d266a14. Candidate 2 independent-review SHA-256: dc5d23c076d35a1862e4a7518ba365abbb23cc9ae49c8fd75f79935d02738c72.

Gabriel's existing decision comment, author gabriel, created 2026-10-03T03:48:38.663584Z, approves the architecture and documents-only specification, raw linear-memory JSON ABI, domain-neutral names, non-executing MuseHub and Aaron's reference work. It retains real-history, mixed-peer and measured status-overhead conditions. It does not supply the eight owner dispositions requested here. Aaron's earlier prototype-review comment requests decisions; it does not supply these dispositions. Secondary continuity handover narration cannot provide the missing owner authority.

The read-only issue/comments refresh at 2026-10-09T01:44:38.862738+00:00 found the same two prior comments, with no next cursor and no newer equivalent request or closing disposition. This describes the refresh before this comment.

Required reply for each item

Use this structure for every decision:

  • Decision ID; owner name and accountable role; decision date.
  • Explicit approved choice or explicit deferral, including every requested exact value; scope and gate; rationale and consequence of deferral.
  • Evidence paths or immutable links, exact byte lengths and whole-file SHA-256 hashes, and whether each artifact is independently accessible.
  • For joint-owner items, both joint owners' written decisions, or an explicit recorded delegation naming delegator, delegate, authority and scope. Where an item names more than two authorities, each required authority must be covered.

Evidence and access

The questions and evidence summaries below are complete in this comment. Contract citations such as 02-execution.md:93 are source labels within the exact candidate identified above, not claims of published attachments or remotely accessible files. Candidate 2 and the newly preserved packet/review remain local, uncommitted and unpushed. No candidate-2 publication URL is asserted. The already published prototype review provides the earlier interface evidence; its whole-file SHA-256 is 8b517a8c263c8b0ff536bf3079d332c6b432198c72836d4574d7236fae5bbbfe. That published document is not candidate 2.

This request faithfully adapts the reviewed Gate 1d packet, SHA-256 bbc75161f363eb588d20a95ec9fbde06a403336a8d0248fc008fa51099bc2c97, and its independent bounded review, SHA-256 5709748e1b2d33d8c4824b32fe6c44c630ccfb2e3c25681171621881c5ea7a6f. Those historical artifacts retain their original unsent status; this is the issue-facing request, not a claim they were published or owner-approved. If evidence is inaccessible, record that access gap and defer the affected conclusion. A digest or a summary is not a substitute for inspecting the evidence.

R1 — Aaron/Muse runtime + VideoFactory — Gate 1 selection; Gate 3 enforcement

Question: Which exact engine/version, engine build digest, runner source/build digest, OS/architecture, sandbox implementation/version, compiler/cache policy and canonical runtime-profile bytes/digest are approved? Which module digest is the compatibility target, and where is the instruction/import/export/memory/table and full candidate-limit compatibility report for each claimed platform? Recommendation — UNAPPROVED: Select one realizable, fully pinned profile per supported platform, subject to actual module compatibility. Evaluate the existing wasmi 0.40.0 prototype as an input, not an approved runtime. Explicitly refuse platforms for which the profile cannot be implemented. Do not invent build/profile hashes. Alternatives: Another pinned compatible engine/profile; or an explicit statement that no compatible realization exists yet, retaining R1 OPEN. Evidence: 02-execution.md:93,116,128; 07-evidence.md:158. The available prototype module is 968,524 bytes, SHA-256 e6d9c3110fb9960f8e221812e140623b401c93de6be3616f3a9da3424653ac00. It retains vt_* exports, 32 MiB live allocation and 16 MiB output ceilings. Empty imports and arithmetic do not prove the proposed profile. The availability audit reverified its bytes; it did not execute it or validate its complete opcode set. Consequence of deferral: Gate 1 runtime selection and B1 remain blocked. Isolation/capacity enforcement is still Gate 3, not established by a selection decision.

S1 — VideoFactory — Gate 1 schema and import/refusal decision

Question: What exact pilot schema ID, canonical schema bytes/digest and delta schema are adopted? Is /1-to-/2 migration supported? If yes, name a deterministic rule deriving every required extent field from explicit source evidence and pin its fixtures. Otherwise explicitly adopt unsupported refusal with exact class, code and expected fixtures. No inferred or guessed extent is acceptable. Recommendation — UNAPPROVED: Adopt native /2 with explicit extent and expressly refuse /1-to-/2 until a complete deterministic rule is approved. Pin the actual schema bytes; this recommendation does not allocate their identity. Alternatives: A complete named deterministic import rule with evidence/fixtures; or another explicitly selected pilot schema with its migration/refusal matrix. Evidence: 01-abi.md:147; README.md:59; MuseHub continuity handover, schema-migration gap 9. The prototype refuses because /1 lacks explicit extent; that behavior is not the required written VideoFactory decision. Consequence of deferral: S1 stays OPEN; H1 and valid H3 transition evidence remain blocked.

P1 — Aaron + Gabriel — Gate 1 identities and production trust-root ownership

Question: What canonical production HTTPS registry origin, immutable publisher ID and publisher-scoped plugin ID are allocated? Who owns the production trust root, and what explicit authority binds the publisher key to that tuple? Supply the authoritative public-key identity/authorization record if already allocated; do not generate or sign anything in this lane. Recommendation — UNAPPROVED: One stable VideoFactory publisher/plugin tuple, one accountable trust-root owner, explicit publisher-key authorization and private-reader grants. Retain the approved single-publisher scope without organization delegation. Alternatives: Another explicitly authorized registry/identity tuple/root owner; or defer selection and retain nonproduction-only examples. Evidence: 03-release.md:13,69,78; Gabriel's single-publisher pilot direction. example.invalid, fixture names and the RFC test key provide no production authority. Consequence of deferral: P1 and authentic pilot identity/transition evidence remain blocked. P2 update/revocation is separately required at Gate 2 before activation or writes.

H1 — Muse + VideoFactory — Gate 1 lossless state/source/asset mapping

Question: What exact repository path-to-document/source/asset mapping is approved, including original-byte retention, canonicalization, path validation, all file roles, asset identity and missing/oversized-asset refusal? Which pinned input and output manifests prove lossless import, restore, complete diff reconstruction and migration, including candidate transport's unfragmented legacy-asset limit? Recommendation — UNAPPROVED: Retain the complete flat host snapshot and original source/asset bytes; link the semantic document through an explicit deterministic mapping. Supply accepted/refused fixtures and exact manifests/hashes. Limit the pilot to assets the candidate framing can carry, with an explicit unsupported refusal beyond that scope; do not silently omit assets to make the corpus pass. Alternatives: Another complete mapping with equivalent losslessness; or a narrower owner-approved pilot scope with complete preservation/refusal fixtures. Evidence: 01-abi.md:109; 04-history.md:53,140,200; 06-vectors.md:43. Existing toy operation records refer to a snapshot that does not contain their domain state. Consequence of deferral: H1 conformance and valid H3 activation/upgrade/rollback/merge-align evidence remain blocked; a semantic projection is not source preservation.

H2 — Muse/MuseHub protocol owners + Gabriel — Gate 1 allocation and peers

Question: Are binary outer version 2, sections 1–6 (including section-6 external records), muse.external-wire/1 and external-domain-v1 formally allocated? Supply the exact authenticated route/method, request/response media types, negotiation fields and integrity binding, HTTP status/error matrix, stripped/unknown-feature refusal behavior and supported old/current client/server builds with hashes for binary, structured JSON and structured msgpack transport. Recommendation — UNAPPROVED: Confirm the already reviewed candidate framing if allocation is available. Record one explicit authenticated route/media/feature/status contract and exact supported builds. Require refusal before durable ingestion/ref advance; do not fall back to legacy representation for bound history. Alternatives: Other collision-free allocations, which require separately reviewed changed candidate bytes; or defer allocation and retain unsupported endpoints. Evidence: 04-history.md:150,156,207,238,278,287; independent review finding 1. Passing bounded codec checks is neither version registration nor route proof. Consequence of deferral: H2 and H3 stay OPEN. Gate 2 reader implementation/acceptance remains later.

L1 — Muse integrity owner + Gabriel — Gate 1 exact baseline disposition

Question: Do you acknowledge these exact 1,080 distinct sorted (kind,id,error) legacy signature-failure rows, and will you open a separately scoped integrity investigation? Record its owner/scope, or explicitly decline with rationale and gate impact. The exact 1,080-row artifact, identified as legacy-signature-failure-rows.json, is 328,257 canonical JSON bytes with no trailing newline and whole-file digest: sha256:1dff08c3d7dc6f645de54227a335c2faa9407636947b1752328a731052dbb7f1. It is not attached or remotely published by this comment. Its bytes were derived as the sorted array of [kind,id,error] triples from baseline-verify.json (360,189 bytes; SHA-256 c73a0dfe75efe68b21e20909b4630a964d007723b4484d2f6a014e088aba45e6), then compared for exact equality with history-spike-rerun.json's failure rows (377,319 bytes; SHA-256 4429074de30b52b73a84d0d97cf24d301d4d4499a347f0f8c85aceaabd898c2a). Both source reports are manifest-bound candidate evidence. If you cannot access and inspect these exact rows, record the evidence-access gap and defer L1; acknowledgment of the digest alone cannot close L1. No evidence upload is requested or authorized by this comment. Recommendation — UNAPPROVED: Acknowledge the unexplained baseline and authorize a separate read-only investigation. Preserve every row and all old history unchanged. Alternatives: Acknowledge and expressly decline investigation with rationale; or defer acknowledgment, retaining L1 OPEN. Acknowledgment does not establish valid signatures, a benign cause, tampering, a waiver or successful verification. Evidence: 07-evidence.md:70,82,88,120; manifest-bound baseline-verify.json and history-spike-rerun.json. The locally preserved row artifact is an exact extraction compared against both reports, not a new verify run or diagnosis. Persisted history still matches the prior 4,288-file inventory. Consequence of deferral: Gate 1 remains blocked. No answer authorizes repair, re-signing or rewrite. Exactly 11,472 promised objects remain unfetched under Gate 2 L2.

B2 — Gabriel/Muse CLI owner — Gate 1 numerical budgets, before B1

Question: For every pilot fixture class and platform, supply maximum full-command cold p50/p95/p99 milliseconds, warm p50/p95/p99 milliseconds and cold/warm maximum unexpected-failure rates, with denominator/classification and interactive-status acceptance rule. Record this matrix before any B1 measurements run. Required row: platform/build/profile; fixture ID/hash/class; cold p50_ms, p95_ms, p99_ms, failure_rate_percent; warm p50_ms, p95_ms, p99_ms, failure_rate_percent; failure denominator; expected-refusal classification; interactive enablement rule. Recommendation — UNAPPROVED: Separate numerical cold/warm budgets per fixture/platform, using two fresh workers. Propose 0% unexpected failures; latency values must come from Gabriel/Muse CLI. Expected malformed-input refusals must be reported separately. The proposed 0% is not approved, and no runtime hard deadline is a latency budget. Alternatives: Explicit numerical budgets for defined pilot tiers; or explicitly defer interactive status and request a reviewed change to the Gate 1 surface. Evidence: 07-evidence.md:174–207; Gabriel's prototype decision 3 requests measured overhead but gives no numerical thresholds. Consequence of deferral: B1 must not run. Deferring interactive status does not satisfy the current required B1 gate, and built-in status/synthetic timings do not substitute.

V1 — Aaron/Muse conformance + VideoFactory — Gate 1 fixtures; Gate 3 execution

Question: Supply exact pilot-valid fixture recipes, seeds/parameters, schema/core revisions, expected outputs/refusals, expanded byte lengths and SHA-256 hashes: approximately 1 KiB, 64 KiB, 1 MiB, near 16 MiB; representative projects; clean, one-edit and many-edit status; malformed refusal; simultaneous maximum merge; and every applicable runtime/transport boundary at limit-1, limit and limit+1. Identify the validator and proof of domain validity. Label intentionally invalid or over-limit cases with exact expected refusals instead of claiming validity. Recommendation — UNAPPROVED: Pin deterministic recipes under S1 and H1, independently validate semantics, and state nearest attainable valid sizes exactly. Preserve separate Gate 3 actual runtime capacity and repeatability certification. Alternatives: An explicitly narrower pilot with reviewed limits and corresponding valid/refusal fixtures; or defer delivery and retain V1 OPEN. Evidence: 06-vectors.md:83,119; 07-evidence.md:165,191. The 45 resource recipes are platform shapes. The available 162 JSON domain fixtures top out at 1,665 bytes; they do not supply the large valid corpus. Consequence of deferral: Gate 1 V1 and representative B1 remain blocked. Shape-valid JSON and memory arithmetic cannot certify domain validity or capacity.

H3 — Muse/MuseHub owners — Gate 1 real-system design evidence (BLOCKED / NOT RUN)

Required delivery: owner-approved exact supported clients/server builds; H2 route contract; safe disposable server/database with durable storage and no production configuration; valid already-existing signed history/transition and ancestry fixtures; persistence/ref and guest-call instrumentation. Existing tests/conftest.py must not run: it uses MemoryBackend/fake authentication and drops/recreates/truncates its configured database. Existing compose configuration uses .env and persistent volumes; it is not proof of a disposable harness. Local source/dependencies are not the supported-build matrix. The read-only availability audit found no candidate-compatible harness; Docker daemon is unavailable and Postgres tools were not on PATH. No service was started.

Required route evidence: real binary and structured JSON/msgpack HTTP, actual authentication/negotiation, ingest, durable persistence, reconstruction, cache, repair, bundle, clone/fetch/push and expected-head guards; valid activation, upgrade, rollback and merge-align; downgrade after either parent, hidden bound ancestry, unavailable ancestry, stripped/unknown negotiation and supported old client refusal. Each run must pin inputs/builds, record raw outcome/digest and before/after persistent stores/refs, preserve old IDs/signatures, show refusal before persistence/ref advance, and instrument zero guest calls for generic work. Existing dictionaries, supplied parent lists, extracted decoders and zero-history codec tests do not discharge a row. No new signing, activation or new-format writes are authorized by this request; owners must supply an in-scope existing disposable evidence path. If unavailable, H3 remains OPEN rather than starting Gate 2 to manufacture prerequisites.

B1 — Aaron/VideoFactory + Muse CLI/runtime — Gate 1 real status evidence (BLOCKED / NOT RUN)

Required delivery before running: recorded B2; approved R1; candidate-compatible real CLI/adapter/runtime status path; S1/H1/V1 fixtures; pinned CLI/module/profile, platform/hardware and safe disposable measurement environment. The available prototype and built-in status path do not meet these prerequisites. Then use two fresh workers/instances for snapshot+diff, at least 100 cold and 1,000 warm full CLI invocations per fixture/platform. Cold: absent compilation cache. Warm: authenticated compilation cache and primed OS page cache, but new CLI and workers. Preserve all samples/failures and digests; report nearest-rank p50/p95/p99, component timings, worker count and RSS/linear-memory/fuel high-water marks. Record expected refusals distinctly. The candidate's one-worker/two-fresh- instance alternative is experimental only and cannot replace this policy without an explicit reviewed revision. No synthetic or built-in benchmark was run.

Later gates and candidate 3

E1: Aaron/VideoFactory must supply complete independently accessible custody before Gate 2 relies on prototype properties. Selected matching local pins do not close E1. P2: Muse/MuseHub trust owners must define authenticated update and revocation before Gate 2 activation/execution/writes. L2: Muse transport owner; exactly 11,472 promised objects remain an explicit Gate 2 deep-verification limitation and were not fetched.

Only once every Gate 1 owner disposition and required H3/B1/V1 evidence is present may candidate 3 be assembled in a new directory, with a new path-sorted manifest and exact digest, all validators rerun, and a fresh independent reviewer given its final bytes. Candidate 2's review cannot be assigned to changed bytes. F1: Gabriel decides freeze after the new independent review. No candidate 3, candidate-3 digest or candidate-3 independent-review prompt is issued now.

○
aaronrene 13 days ago

Follow-up to the reviewed Gate 1 owner request. Aaron has approved the following proposed directions in discussion. They do not establish another owner’s approval, delegation or evidence access. Candidate 2 remains UNFROZEN, identified by manifest SHA-256 0169befe5fb7afbce52505c7ecda855567be47ce0e27517e00f247c67d266a14. The existing architecture approval and reviewed transport/resource corrections remain unchanged. Please supply only the missing confirmations and existing evidence below. For each item, record decision ID; owner name/role/date; exact approved values or explicit deferral; scope/gate; rationale; evidence location, exact byte length and whole-file SHA-256; and accessibility. Cover every required authority through written confirmation or explicit scoped delegation. Missing evidence leaves the item open; this request does not authorize its generation. R1 — Aaron/Muse runtime + VideoFactory: Confirm qualification of wasmi 0.40.0 first on one macOS Apple Silicon profile, using a fresh disposable worker without ambient capabilities and with explicit limits. Supply exact engine/build, runner source/build, OS/architecture, sandbox implementation/version, compiler/cache policy, canonical profile bytes/digest, final module identity and complete module-feature/limit compatibility report. Unsupported platforms must refuse explicitly. S1 — VideoFactory: Formalize native /2 with explicit extent and unsupported /1→/2 migration until a separately approved deterministic rule exists. Pin the actual schema and delta-schema bytes/identities, stable refusal class/code and expected fixtures. Specify the exact mapping into candidate 2’s document/canonical representation, including native integers beyond its JSON-number ceiling. Existing LossyMigration text alone does not pin the final ABI code. P1 — Aaron + Gabriel, with responsible Muse/MuseHub trust authority: Aaron/VideoFactory is the proposed publishing owner. Supply the production HTTPS registry origin, stable publisher/plugin IDs, accountable trust-root owner, existing publisher public-key identity/authorization and required reader grants. This requests existing allocations only; no identity or key creation, signing or publication is authorized. H1 — Muse + VideoFactory: Confirm preservation of the complete flat project snapshot, original source/assets, paths, metadata and relationships, with /2 as an additional representation. Pin the complete mapping, canonicalization/path-validation rules, asset identities and missing/invalid/oversized refusals. Identify existing manifests and lossless import/restore/full-diff/migration fixtures, including the unfragmented legacy-asset restriction. Record any missing proof explicitly. H2 — Muse/MuseHub protocol owners + Gabriel: Confirm formal allocation of proposed binary version 2, sections 1–6, muse.external-wire/1 and external-domain-v1. Supply authenticated routes/methods, request/response media types, negotiation/integrity bindings, status/error matrix and exact supported old/current client/server builds for binary, JSON and msgpack. Require incompatible or stripped negotiation to refuse before persistence/ref advancement, with no lossy fallback. MuseHub remains non-executing. L1 — Muse integrity owner + Gabriel: Both owners must identify where they accessed and inspected the actual 1,080 rows and explicitly acknowledge them: 328,257 canonical JSON bytes, no trailing newline, SHA-256 1dff08c3d7dc6f645de54227a335c2faa9407636947b1752328a731052dbb7f1. Confirm the separately scoped read-only investigation’s accountable owner, scope and gate impact, or explicitly defer. These rows are not attached by this comment; inaccessible rows or digest-only acknowledgment leave L1 open. No investigation, repair, re-signing, rewriting or fetching starts under this request. B2 — Gabriel/Muse CLI owner: Confirm or revise the ordinary-scene full-command proposal: cold p50/p95/p99 1,000/2,000/3,000 ms; warm 250/500/1,000 ms; zero observed unexpected failures; expected refusals reported separately. Complete the matrix for every fixture class/platform, including large and near-limit, with exact fixture/build/profile identities, cold/warm failure-rate limits and denominators, classification and interactive-status acceptance rule. Preserve the candidate’s two-fresh-worker policy. No measurements are authorized. V1 — Aaron/Muse conformance + VideoFactory: Under pinned S1/H1, identify existing deterministic fixtures for small/medium/large/near-limit representative projects, clean/one-edit/many-edit cases, simultaneous maximum merge, malformed/missing-asset refusals and applicable limit−1/limit/limit+1 boundaries. Supply recipes/seeds/parameters, schema/core revisions, exact lengths/hashes, expected results and independent domain-validity evidence. Record unavailable evidence and its owner/gate. Fixture generation requires separate authorization; active Scene 1 and Scene 2 files must remain untouched. H3/B1 remain blocked pending complete prerequisites and separate execution authorization. Deferral is neither approval nor waiver. Exactly 11,472 promised objects remain unfetched under Gate 2 L2. This comment authorizes no implementation, services, tests, measurements, signing, uploads, new-format writes or Gate 2 work.

○
aaronrene 13 days ago

Concrete recommendations for Gate 1 owner review

Prepared by Aaron's assistant at Aaron's request, to make the remaining choices easier to review. These are proposals, not completed owner dispositions, measured results or implementation authority. The earlier directional choices stand; the added identifiers, representation details and budget tiers below are new recommendations for approval or correction.

Reference: the owner-confirmation follow-up. Candidate 2 remains UNFROZEN at manifest SHA-256 0169befe5fb7afbce52505c7ecda855567be47ce0e27517e00f247c67d266a14. Its local contract and evidence are supporting material, not newly published attachments. No candidate bytes are changed by these recommendations.

  1. R1 — start with one controlled Mac pilot. Recommend qualifying wasmi 0.40.0 first on one explicitly named macOS Apple Silicon OS/build and hardware profile. Retain candidate 2's fresh process and instance per operation, no ambient capabilities, hard limits and explicit unsupported-platform refusal. Approve a realization only after exact engine/runner/module/profile identities and a full feature/limit compatibility report exist. Do not assume the existing prototype meets those requirements, or silently weaken a limit if it does not. Exact sandbox implementation, compiler/cache policy, OS/build and artifact digests remain owner-supplied facts. Owners: Aaron/Muse runtime + VideoFactory; Gate 1 selection, Gate 3 enforcement proof.

  2. S1 — preserve native /2; make the boundary conversion explicit and lossless. Recommend native video_timeline/2 with authored frame_count, and no automatic /1 to /2 conversion. Propose final forward-refusal class/code migration / explicit_extent_required; retain reverse-conversion refusal, with proposed code extent_not_preserved. These codes are unallocated proposals. Native /2 accepts 64-bit integers, while candidate 2's CJ1 numeric ceiling is +/-9007199254740991. Recommend a separately identified boundary schema with fixed canonical decimal-string representation for native 64-bit integer fields, consistently across state, operations and conflicts; preserve each field's native range and forbid leading zeros, plus signs and negative zero. Use checked, reversible conversion, never rounding or truncation. Keep native core bytes and identity rules intact; different boundary bytes need their own schema/identity rules. VideoFactory must review this mapping, pin schema/delta-schema bytes and refusal fixtures, and prove round trips before adoption. Owner: VideoFactory, with Muse review of the shared boundary; Gate 1.

  3. P1 — one publisher, one plugin, explicit permission. Recommend Aaron/VideoFactory as accountable publishing owner; propose publisher ID videofactory and plugin ID video-timeline, subject to availability and formal allocation. Use the MuseHub production registry designated by its responsible owner; do not assume the staging issue host is the production registry. Recommend one explicitly named Muse/MuseHub trust-root custodian and an explicit authorization tying the existing publisher public key to this registry/publisher/plugin tuple, with named private-reader grants. No inherited publication permission, automatic installation or automatic upgrade. Actual registry origin, allocation, key identity and authorization remain unverified until their owners supply them. Owners: Aaron + Gabriel and the responsible Muse/MuseHub trust authority; Gate 1, with P2 still later.

  4. H1 — preserve the whole project and prove it can be restored. Recommend a complete flat host snapshot of every required original source/asset byte, path, metadata item and relationship. Add the semantic timeline through an explicit mapping manifest identifying each file's role, path, length, hash and relationship to the semantic state. Validate paths and refuse missing, invalid or unsupported assets; do not silently discard anything. Prove import, restoration, full comparison and permitted migration using complete before/after manifests. Keep working Scene 1 and Scene 2 files untouched. Candidate 2 cannot fragment a legacy asset record: it must fit within a 64 MiB frame after overhead. That can exclude real movie assets; do not promise those projects are supported. Recommend source-free pilot assets that fit, while recording larger-asset support as a separate future design decision, without narrowing preservation claims or waiving Gate 1 proof. Owners: Muse + VideoFactory; Gate 1.

  5. H2 — keep the reviewed format and refuse unsafe transfers. Recommend formal allocation, if available, of binary version 2, sections 1-6 including external section 6, muse.external-wire/1 and external-domain-v1. Require authenticated negotiation, complete required-history preservation and refusal of unknown, stripped or incompatible negotiation before durable ingestion or branch-reference advance. Keep MuseHub non-executing. The protocol owners should supply their existing route/method/media/status conventions and exact supported old/current build identities; do not invent endpoints or claim that codec probes establish deployed support. If an allocation conflicts, defer and request a separately reviewed change. Owners: Muse/MuseHub protocol owners + Gabriel; Gate 1 allocation, H3 proof still pending.

  6. L1 — inspect the existing failures, then decide a separate investigation. Recommend the Muse integrity owner as accountable investigation lead, jointly confirmed by Gabriel. Both must access and explicitly acknowledge the actual 1,080 rows: 328,257 canonical JSON bytes, no trailing newline, SHA-256 1dff08c3d7dc6f645de54227a335c2faa9407636947b1752328a731052dbb7f1. Recommend a separately authorized, read-only investigation to identify the cause and report gate impact. A summary or digest alone cannot close L1; if the rows are inaccessible, record the access gap and defer. No diagnosis, repair, re-signing, rewriting or object fetching is proposed as an authorized action here. Owners: Muse integrity owner + Gabriel; Gate 1 disposition.

  7. B2 — approve numerical targets before measuring. Recommend the following provisional full-command budgets for the single R1 pilot profile. They are proposed acceptance targets, not performance predictions or measurements:

Fixture class Cold p50 / p95 / p99 (ms) Warm p50 / p95 / p99 (ms)
Small (~1 KiB), medium (~64 KiB), and representative ordinary-scene projects 1000 / 2000 / 3000 250 / 500 / 1000
Large (~1 MiB), outside the ordinary-scene class 2000 / 4000 / 6000 500 / 1000 / 2000
Near-limit (nearest valid size at or below 16 MiB), outside the ordinary-scene class 5000 / 10000 / 15000 1000 / 2000 / 4000

Sizes refer to complete candidate semantic-document bytes, not source-video sizes. Pin file/asset/operation counts too. Classify fixtures before measurements; the stricter ordinary-scene row applies to any fixture labeled ordinary regardless of size. Apply each row to clean, one-edit and many-edit cases. Refusal fixtures must have their exact expected result and applicable timing row declared in advance and be reported separately. Recommend 0% observed unexpected outcomes in every cold/warm fixture cohort: unexpected outcomes divided by all attempts in that cohort, with every attempt and duration retained. An unexpected refusal, timeout or incorrect result is a failure. Expected refusals are not hidden successes.

Retain two fresh workers for snapshot+diff and the existing minimum 100 cold/1000 warm samples per fixture/platform. Recommend a visible working indication by 250 ms when unfinished, and never displaying a completed clean result before successful validation. Enable default interactive use only after correctness, zero-unexpected-outcome and all approved class budgets pass; failures require an explicit reviewed scheduling/scope decision, not omitted samples, relabeled fixtures or a silently relaxed target. Exact fixture hashes, R1 platform/build/profile and the complete matrix remain required before B1. Owner: Gabriel/Muse CLI; Gate 1, before B1. No measurement is authorized.

  1. V1 — use reproducible test projects covering success and refusal. Recommend deterministic source-free /2 fixtures at the four size tiers above, plus representative movie structure, clean/one-edit/many-edit cases, simultaneous maximum merge, malformed/missing-asset cases, every applicable limit-1/limit/limit+1 boundary, and exact integer-conversion/refusal boundaries from S1. Record nearest attainable valid sizes rather than padding invalid JSON. Pin each recipe/seed/parameter set, schema/core revision, input/output length and hash, expected result and independent domain-validity result. Existing small fixtures may be reused only when their exact scope matches; generic resource probes do not establish domain validity. Preserve active movie files. Owners: Aaron/Muse conformance + VideoFactory; Gate 1 fixture proof, Gate 3 execution/capacity later. Fixture generation needs separate authorization.

Requested review: Gabriel's agent can check these proposals against the exact contract and existing evidence and recommend corrections. Each accountable owner must then record the decision ID, name/role/date, exact approved choice or explicit deferral, scope/gate, rationale and accessible evidence paths/immutable links with exact lengths/SHA-256. Joint decisions require every named authority or an explicit scoped delegation. An agent's review or a general 'looks good' does not manufacture missing evidence or another owner's approval. Please do not generate absent artifacts under this request.

Keep approval of direction separate from completion of evidence and authority. All incomplete items remain OPEN; explicit deferral is not a waiver. H3/B1 remain blocked and unrun. Exactly 11,472 promised objects remain unfetched under Gate 2 L2. E1/P2 remain later requirements. This comment authorizes no implementation, services/tests, benchmarks, fixture generation, investigation, identity/key allocation, signing, upload, history changes, candidate changes or Gate 2 work.

○
gabriel 1 day ago

Gate-1 dispositions. Replying to the concrete recommendations above — approving them as the owner decisions, not just acknowledging the proposals.

L1 — resolved, not deferred

This isn't an open investigation anymore. I had my agent check it directly: the 1,080 rows reproduced exactly (1,080 signature failures, 11,475 promised objects — matches your numbers almost exactly) against gabriel/muse on staging. Root cause: the same rc10 object-store migration corruption we just found and fixed in gabriel/musehub this week (stamped a spurious signer_public_key/signature onto historical commit rows without recomputing commit_id). Canonical local history had 0 failures the whole time — the corruption was server-side-only, same as musehub. This also closes #107 (filed separately against the same 1,080 rows with a more detailed root-cause writeup) — its "original signing is unrecoverable" premise was incorrect; the correct signatures were never lost, just never pushed to staging's stored copy.

Repaired using the same script/mechanism hardened for musehub (deploy/repair_commit_signatures.py, wire_repair_commit). Final result on staging: 1,079 of 1,080 repaired, fresh-clone-verified at 0 remaining failures across 2 follow-up passes. One commit (sha256:2f17e90958a3a39216322972274314b4c495ed995ea0edf4d24a777d171226f7) has a genuinely oversized structured_delta (15.6 MB) that exceeds the /repair-commit endpoint's request body limit (HTTP 413) — needs a scoped follow-up (raise the limit or chunk the request for this endpoint specifically), tracked separately, not blocking Gate 1. Production's gabriel/muse was already clean (0 failures) — the corruption never reached production's database.

No reinterpretation of your prior history/mixed-peer/status-overhead conditions is implied by this — it's a separate storage-layer bug, not evidence against the migration design.

Decision: Muse integrity owner: gabriel, 2026-10-21. Resolved via direct repair (1,079/1,080 on staging, confirmed by fresh clone + muse verify), not a deferred investigation. One known remaining exception (oversized structured_delta, tracked separately). Scope: storage-layer signature corruption, unrelated to the external-domain contract itself.

R1 — approved as proposed

wasmi 0.40.0, one named macOS Apple Silicon profile, fresh disposable worker per operation, no ambient capabilities, explicit unsupported-platform refusal. Go pin the exact engine/runner/module/profile identities and run the full feature/limit compatibility report — that's the deliverable, not a decision I need to make twice.

S1 — approved as proposed

Native video_timeline/2 with authored frame_count, no automatic /1→/2 migration, explicit refusal (migration/explicit_extent_required forward, extent_not_preserved reverse — fine as proposed, final allocation is yours to confirm). Canonical decimal-string boundary schema for native 64-bit integers beyond CJ1's ceiling, checked/reversible conversion, no rounding. VideoFactory owns pinning the actual schema bytes and proving round-trips.

P1 — approved as proposed

Aaron/VideoFactory as publishing owner, videofactory/video-timeline as the proposed IDs (subject to actual availability check), single-publisher scope, no org delegation for v1 — consistent with what I asked for Oct 3. Use the actual MuseHub production registry, not the staging issue host, for the real allocation.

H1 — approved as proposed

Complete flat snapshot, original bytes preserved, explicit mapping manifest, refuse anything that doesn't fit the 64 MiB frame rather than silently dropping it. Source-free pilot assets for now is fine — note the larger-asset gap as a separate future design item, don't let it block Gate 1.

H2 — approved as proposed

Binary version 2, sections 1-6, muse.external-wire/1, external-domain-v1 — allocate these if the slots are actually free. Refuse incompatible/stripped negotiation before persistence or ref advance, no lossy fallback, MuseHub stays non-executing. If any of these collide with something already allocated, come back with the conflict rather than silently picking an adjacent number.

B2 — approved as proposed

The three-tier budget table (ordinary/large/near-limit, cold and warm p50/p95/p99) and the 0%-unexpected-outcomes target are approved as the acceptance thresholds. Run B1 against these once R1/S1/H1/V1 prerequisites are in place.

V1 — approved as proposed

Deterministic source-free fixtures at the four size tiers, clean/one-edit/many-edit, simultaneous max merge, malformed/missing-asset refusals, limit±1 boundaries. Go generate them.

This authorizes the Gate-1 dispositions above — proceed to pin the exact artifacts/digests each item calls for and bring the real values back for Gate 2. Still not an authorization for packaging, signing, installation, registration, deployment, or any production change.