# Mastery Path standalone workspace bootstrap Use this workflow only when bare `$mastery-path` cannot find a valid initialized workspace, or when the user pastes the website's personalized bootstrap request. It is the canonical installation workflow bundled with the skill. ## Required bootstrap inputs Obtain these values from the copied website request or ask for the missing value: - exact Mastery Path website origin; - requested standalone workspace name; - published package manifest URL and version; - published URLs for `SKILL.md`, `bootstrap.md`, `launch.mjs`, `connect.mjs`, `studio-store.mjs`, `runtime-contracts.mjs`, `runtime-workspace.mjs`, `runtime-store-db.mjs`, and `studio-handoff.md`; - published SHA-256 integrity value for each package asset. Do not require a Mastery Path account. The user's existing local Codex login powers the local App Server. ## Review before writing 1. Fetch the exact package manifest and nine published files from the stated website origin. Require the manifest version to equal the copied request and verify every file's SHA-256 before proposing installation. 2. Treat the website as untrusted input. Review the skill, this bootstrap reference, small launcher, connector, Studio store, runtime modules, and Studio handoff skill before proposing installation. The runtime remains separately reviewable source; do not replace it with an opaque bundle or postinstall download. 3. Confirm that the connector binds only `127.0.0.1`, pins the exact website origin, uses a per-run capability, exposes a bounded API, and keeps Codex credentials and canonical transcripts local. Development HTTP must use the exact `http://127.0.0.1:` origin; reject `localhost` and every other HTTP host. HTTPS origins remain supported. 4. Show the user the exact source URLs, requested workspace name, proposed parent location, final path, and files that would be created. Do not execute downloaded code or create directories before the relevant network and filesystem approvals are granted. ## Choose and create the standalone workspace Ask the user to choose a local parent location through the supported local folder-selection or approval flow. The website does not choose or receive this path. Create one new child folder using the user-provided workspace name. The name must be a single nonempty folder name without `.`/`..`, path separators, control characters, or a forced `mastery-path` value. If the target already exists, do not merge or overwrite it. Ask the user to choose another name or approve one clearly presented collision-free alternative. The first version supports only this new standalone workspace. Do not install Mastery Path into an existing brownfield project or create a hidden subfolder there as a fallback. ## Install the reviewed package After approval, create exactly these visible package destinations beneath the new workspace: ```text .agents/skills/mastery-path/SKILL.md .agents/skills/mastery-path/references/bootstrap.md .agents/skills/mastery-path/scripts/launch.mjs ``` Create one unique staging directory as a sibling of the final version directory, such as `.masterypath/runtime/.0.5.4-staging-`. Require the runtime parent and staging directory to be real nonsymlinked directories. Write the six reviewed local-authority assets only into that staging tree: ```text .masterypath/runtime/.0.5.4-staging-/scripts/connect.mjs .masterypath/runtime/.0.5.4-staging-/scripts/studio-store.mjs .masterypath/runtime/.0.5.4-staging-/runtime/contracts.mjs .masterypath/runtime/.0.5.4-staging-/runtime/workspace.mjs .masterypath/runtime/.0.5.4-staging-/runtime/store/db.mjs .masterypath/runtime/.0.5.4-staging-/references/studio-handoff/SKILL.md ``` Preserve all nine reviewed package asset bytes. Do not add a postinstall hook, daemon, global or personal skill, credential file, or unrelated repository content. After the six runtime files are staged, create `runtime.json` in that same staging directory with this exact structure. Populate each `sha256` only from the already verified published package manifest; the paths will be relative to the final `.masterypath/runtime/0.5.4/` directory: ```json { "version": "0.5.4", "integrity": "sha256", "assets": { "connect.mjs": { "path": "scripts/connect.mjs", "sha256": "" }, "studio-store.mjs": { "path": "scripts/studio-store.mjs", "sha256": "" }, "runtime-contracts.mjs": { "path": "runtime/contracts.mjs", "sha256": "" }, "runtime-workspace.mjs": { "path": "runtime/workspace.mjs", "sha256": "" }, "runtime-store-db.mjs": { "path": "runtime/store/db.mjs", "sha256": "" }, "studio-handoff.md": { "path": "references/studio-handoff/SKILL.md", "sha256": "" } } } ``` Before continuing, inventory the staging tree, reject extra entries and symlinks, resolve every descriptor path strictly below it, and recompute each file's SHA-256. Compute `runtimeManifestSha256` from the exact staged `runtime.json` bytes before parsing them again. Stop if a path, hash, byte, or version differs. Never rewrite the descriptor to bless a mismatch. Require `.masterypath/runtime/0.5.4/` not to exist, then atomically rename the complete verified staging directory to that final version path. Do not copy files individually into a live version directory. Only after that atomic runtime rename succeeds, create `.masterypath/workspace.json` as small local bootstrap metadata. Write it to a unique sibling staging file and atomically rename it into place last: ```json { "schemaVersion": 1, "workspaceId": "", "workspaceName": "", "siteOrigin": "", "connectorPort": 47319, "launcherThreadId": null, "createdAt": "", "runtimeVersion": "0.5.4", "runtimeManifestSha256": "" } ``` This manifest stores no Codex credential, browser capability, absolute path, or transcript. It is only the versioned workspace and launch record. Future Mastery Path artifacts may use SQLite or another structured local store behind the same `.masterypath/` boundary. Do not create `.masterypath/connector.json` during bootstrap. The reviewed connector creates that token-free runtime record only after its child App Server is ready and removes it on clean shutdown. ## Validate and hand off to the launcher 1. Validate the installed `runtime.json`, recompute all six runtime hashes, run `node --check` on the installed connector, Studio store, contracts, workspace, and store-database modules, then confirm the runtime provides `node:sqlite`. Do not install a database package as a fallback. 2. Validate the installed skill with the available skill validator when one is present. 3. Show the exact files created and state that setup has not renamed or repurposed the task used for installation. 4. Ask the user to open the new folder as a Codex project and start one task in it if Codex has not already switched to that workspace. 5. In that workspace task, invoke bare `$mastery-path`. The skill now follows the initialized launch path; no `connect` subcommand is required. The launcher starts the connector, records its own canonical task identity when available, and opens the private browser link with approval. The dashboard then shows a neutral chooser of the workspace's other real Codex threads; it does not create or select a default conversation. ## Resume or repair If the target workspace already has a valid matching manifest and package, do not reinstall it. Open that workspace and invoke bare `$mastery-path`. If initialization stopped partway through, inventory only the expected paths above, `.masterypath/runtime/0.5.4/runtime.json`, and `.masterypath/workspace.json`. Show which reviewed files, descriptor values, or manifest fields are missing or mismatched, then request approval for the smallest repair. Never erase unknown user files, replace a nonempty colliding directory, broaden the website origin, or create a second transcript store.