# Muse → IBOGA.jp production connection packet

Current update: authenticated gateway published at
https://iboga-muse-gateway.yaoyorozu369.workers.dev . The real registry is reached
through an outbound local relay. Pages credential is installed in Worker
Secrets. Dedicated gateway credential is handed off separately through secure
input; never in the public packet. Muse runtime authentication/preview remain
unverified until Muse executes them.

Current contract: `workspaces/iboga-muse-gateway/README.md` and
https://iboga-maintenance-kit.pages.dev/muse/GATEWAY_START_HERE.md .
The remainder records preparation-stage observations; historical
NOT-provisioned statements are superseded by this current update.

## Muse product identification — official-source correction

2026-10-31: Asahi directed central to research Muse instead of requesting
the service URL/workspace name. Official Meta sources identify the relevant
product as Muse at https://muse.ai, a personal cloud agent with its own
dedicated Linux computer, not a generic CI workspace/Secret-settings service.
The product's official setup contract can be prepared without a workspace name.

Official Help Center: ask Muse to create a Custom Connector for an API not
already listed. Muse guides connection setup and stores credentials in its
Secure Credentials Store. The official security article describes authd and
Sentinel surrogate credentials with secret insertion at the network boundary;
the core agent does not receive actual stored credentials.

Consequences for this handoff:
- Provide the central API endpoint, operation schemas, authentication method,
  scopes, approval semantics and test procedure for Muse to consume.
- Use Muse's actual custom-connector credential flow. Do not assume an ordinary
  workspace-specific environment-secret dashboard or a raw credential file.
- A public Muse URL/workspace name is not needed to research or build the
  generic central adapter. Real credential delivery must still take place in
  the user's actual authenticated Muse credential flow, never in chat/ZIP.
- The previous kit's environment-token Wrangler adapter is not proof of
  compatibility with Muse's surrogate-credential runtime. Direct Wrangler
  authentication needs an actual Muse execution test; an API connector path
  must be evaluated against its documented secure credential handling.
- Do not conflate consumer Muse with the separate Muse Code CLI documentation.
- Do not assume a public connector-directory submission/review is needed for
  the personal Custom Connector described by Meta Help.

Sources verified2026-10-31:
https://www.meta.com/help/superintelligence/1687253048996149/
https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
https://platform.muse.ai/docs
Authority: Asahi's2026-10-31 request for Muse to perform editing, building,
verification, preview and production publication while keeping central gates.
Workspace: Hermes Ops / Track C. No AIQs, payment, DNS or Worker-route edits.

## Verified locally

- Existing Pages project name: `iboga-jp`.
- Existing production branch: `master`.
- Project contains the `iboga.jp` custom domain and current production deployment succeeds.
- All503 current public content routes match the maintained candidate menu/main.
- Muse's Node24/Python3.12 build/check PASS is Asahi/Muse-reported evidence,
  not a new independent execution from the central machine.
- Existing kit builds locally and from clean extraction. It does not provide a
  reachable central registry or an authenticated remote workspace.
- Muse service: identified from official Meta sources as https://muse.ai.
  Actual authenticated custom-connector credential flow: not yet exercised.
- No token has been created, disclosed, rotated or injected in this work.

## Central registry and real scope names

Authoritative local store: `state/website_update_coordination.sqlite3` in
Hermes Ops. Never publish, upload to the handoff ZIP, or sync forked copies.
Current registry:

| Field | Registered value |
|---|---|
| site_id | `iboga.jp` |
| scopes | `blog`, `research`, `other`, `shared-assets`, `site-shell` |
| global scopes | `shared-assets`, `site-shell` |
| required evidence | `canonical`, `production`, `project-preflight`, `visual-qa` |
| lane lease |30 minutes; heartbeat before expiry |
| evidence freshness |15 minutes |

Use `blog` only for isolated Blog content; `research` for isolated Research
content. Shared menus, five-language shell/build/style/assets are global.
Admissions currently has no isolated registered scope: use `site-shell`
conservatively unless a reviewed scope registration changes that policy.
Do not invent `muse`, `muse-blog`, or a new site_id to avoid conflicts.
Full-artifact publication must reconcile all integrated lanes even when
content-edit scopes are disjoint.

## Recommended connection boundary — not deployed

Keep SQLite access on its existing host. Provide an authenticated HTTPS/RPC
facade that executes only fixed coordinator operations on the real DB.
Do not expose raw SQL, arbitrary shell commands, file reads, local paths,
secrets, agent histories or cross-project state. All remote calls must be
restricted to iboga.jp and the explicitly assigned lane/scope.

SQLite WAL uses shared memory and does not support use across a network
filesystem. Even a remote file path alone is not a correct sharing design:
https://sqlite.org/wal.html

The authenticated credential destination must be verified at secret delivery;
this does not block preparation of the generic API/connector contract.
No public endpoint, tunnel,
firewall exception, browser permission or service grant has been created.

Remote self-report must not independently mint approval/evidence PASS.
Remote begin/heartbeat/ready can express state; central integrate/preflight
must use fresh, verified candidate and approval facts. finish must follow
public verification, not just a successful upload command.

## Exact existing CLI lifecycle

Run on the authoritative host, or through its authenticated fixed-operation
adapter. `$LANE` denotes the opaque result returned by begin; `$DIGEST` is
the actual candidate SHA-256 with `sha256:` prefix. These are examples, not
commands to run on a cloned registry.

```sh
python scripts/website_update_coordinator.py status --site iboga.jp
python scripts/website_update_coordinator.py begin --site iboga.jp --scope site-shell --digest "$BASE_DIGEST"
# save returned lane ID privately in the active task
python scripts/website_update_coordinator.py heartbeat --lane "$LANE" --digest "$WORK_DIGEST" --site-shell 1
python scripts/website_update_coordinator.py ready --lane "$LANE" --digest "$DIGEST" --site-shell 1
```

Only after real source/build/runtime/visual/baseline verification, record
fresh sanitized facts centrally:

```sh
python scripts/website_update_coordinator.py evidence --site iboga.jp --kind canonical --status PASS --digest "$DIGEST" --reason VERIFIED_CANDIDATE
python scripts/website_update_coordinator.py evidence --site iboga.jp --kind project-preflight --status PASS --digest "$DIGEST" --reason VERIFIED_PROJECT_CHECKS
python scripts/website_update_coordinator.py evidence --site iboga.jp --kind visual-qa --status PASS --digest "$DIGEST" --reason VERIFIED_VISUAL_PROOF
# production readiness must preserve known deferred failures; never invent a PASS
python scripts/website_update_coordinator.py integrate --lane "$LANE" --candidate-digest "$DIGEST"
python scripts/website_update_coordinator.py preflight --site iboga.jp
# explicit Asahi release approval + matching candidate + fresh PASS precede publish
# real public verification precedes:
python scripts/website_update_coordinator.py finish --lane "$LANE"
```

Never use the sample evidence commands to make a blocking observation vanish.
Known legacy-cache failure is separate: current broad production evidence is
BLOCK/LEGACY_CACHE_STALE. Scoped release handling needs verified nonregression
facts and explicit scope; broad unresolved status must be retained afterwards.
Stale lanes must not be revived by heartbeat; inspect and reconcile first.

## Cloudflare credential handoff contract

Destination secrets: `CLOUDFLARE_API_TOKEN`, `CLOUDFLARE_ACCOUNT_ID`.
Scope: existing account, Cloudflare Pages Edit. No DNS Edit, Workers Routes,
payment privileges or existing Global API Key in the package.
Account-scoped Pages rights must not be described as cryptographically
limited to one project: the adapter additionally verifies project/domain/branch.

Secret injection must happen through Muse's verified Custom Connector
credential flow into its Secure Credentials Store. Never place values in chat, source, ZIP, command arguments,
screenshots or logs. Masked fields must remain masked. Existing credentials
are not assumed to be a suitable transferable Pages-only token.

Official setup:
https://developers.cloudflare.com/pages/how-to/use-direct-upload-with-continuous-integration/

Acceptance: execute `npm run cf:check` inside Muse with its real injected
credentials, then upload a preview and verify it. Local account access or
mocked responses do not prove remote authentication.

## Baseline and source synchronization contract

On each verified publication, produce a versioned release packet containing:

- source-kit version and SHA-256;
- artifact digest, route inventory and current503-route nav/main hashes;
- previous-release digest, verification time and current failure statuses;
- corresponding reviewed source changes, not just a baseline hash reset.

Muse must start from the accepted version and refuse publish if the live
baseline changed. Never run baseline refresh simply to bypass drift.
Following a Muse publication, central source and the next handoff packet
must incorporate the reviewed Muse source changes before any local publish.
Candidate/approval/baseline mismatch always stops publication.

## Release approval contract

Asahi gives the exact release approval in this trusted Track C topic or the
identified Muse workspace. Bind the approval to release ID, candidate digest,
baseline digest, destination project/branch and expiry. An unqualified
persisted `IBOGA_RELEASE_APPROVED=YES` is not a transferable blanket approval.
Central must receive and verify approval before granting that release's
preflight. Proof of remote deploy and public verification closes the lane.
Approval-source integration is not implemented yet.

## Remaining required evidence

1. Real authenticated Muse Custom Connector credential-flow access.
2. Approved transport; authenticated Muse→central request touches the real
   registry, with conflict/stale/mismatch/unauthorized operations blocked.
3. Actual secret injection and Muse-side Cloudflare auth/preview success.
4. Source/baseline round-trip, exact approval, one authorized production
   release executed by Muse, public verification, and final lane closure.

Until these pass, the system is prepared but NOT remote-production-ready.