Mynd Release Path - Obsidian Publish

# Mynd Release Path Mynd Release Path is the public-safe workflow for moving Joe's Mynd changes from Codex and Obsidian into the live public site. ## Meaning This path exists so Joe and Codex do not rely on memory before changing the public Mynd. The release loop is: ```text local Mynd change -> local release gate -> explicit live approval -> Vercel deploy and Obsidian Publish sync -> postdeploy gate -> browser walkthrough -> lived feedback ``` Before any live mutation, run: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run check:mynd-predeploy ``` This prepares and verifies the local release package. It regenerates the AI-readable files, checks the local Mynd manifest, checks the practice discovery to feedback flow, checks publish-route readiness, lints, builds, and reports current live drift. Passing predeploy does not mean live is current. Passing predeploy means the local package is ready for Joe-approved live mutation. Do not deploy Vercel or publish Obsidian changes unless Joe has explicitly approved that live action in the current context. If the next action is unclear, run: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run check:mynd-release-status ``` For machine-readable status, use: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run --silent check:mynd-release-status:json ``` This combines the Vercel/generated-file status with the Obsidian Publish note-body status. It answers: 1. Does `josephniemchak.com` need a launchpad deploy? 2. Does Obsidian Publish need note-body sync? 3. Which critical user-path notes need syncing? 4. Which feeling-path notes need syncing? 5. Which practice result-loop notes need syncing? 6. What verification command comes after deploy and sync? The JSON report includes `releaseSummary`. Use `releaseSummary` first because it names: 1. the current release status 2. the first action 3. the approval boundary 4. the exact approval prompt to ask Joe 5. the safe alternative if approval is not present 6. the live-behind reasons 7. the deploy command 8. the publish order and note counts 9. the publish queue preview 10. the publish queue command 11. the postdeploy verification command Then inspect the detailed queues only when selecting exact notes to publish. Use `releaseSummary.publishQueuePreview` for a quick grouped view of the first stale notes. Use `releaseSummary.publishQueueCommand` for the full queue before taking action. If `releaseSummary.approvalPrompt` is present, ask that exact question before mutating live systems. If approval is not present, follow `releaseSummary.safeAlternative` and keep working locally. When live is behind local, the first command named by `releaseSummary.deployCommand` is: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" && vercel --prod --yes ``` Only run that after explicit live approval. When Obsidian Publish is behind local, the queue command named by `releaseSummary.publishQueueCommand` is: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" && npm run check:mynd-obsidian-content:failed ``` The release summary is guarded by: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run check:mynd-release-summary ``` This check fails if the first action, approval boundary, live-behind reasons, deploy command, publish order, publish counts, publish queue preview, publish queue command, or postdeploy command stops being machine-readable. It also fails if the approval prompt or safe no-approval alternative stops being machine-readable. After Vercel deploy and Obsidian Publish sync, run: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run check:mynd-postdeploy ``` This proves the live manifest, practice flow, feedback report shape, and publish routes are current. After postdeploy passes, do [[Bounded Public Walkthrough]]: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run check:mynd-walkthrough:live:strict npm run check:mynd-obsidian-content:strict ``` If the Obsidian content check fails, get the exact publish queue: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run check:mynd-obsidian-content:failed ``` The failed queue is split into: 1. Critical user-path notes. 2. Feeling-path notes. 3. Practice result-loop notes. Publish the critical user-path notes first because they hold the entry, safety, feedback, release, and agent-reading paths. Then publish the feeling-path notes because they hold the emotionally obvious first choice after a person names how they feel. Then publish the practice result-loop notes because they hold the actual well-being actions and result feedback handoff. After those notes are synced in Obsidian Publish, rerun: ```bash cd "/Users/joeniemchak/Developer/30 Builds/launchpad" npm run check:mynd-postdeploy ``` Use [[Bounded Public Walkthrough]] and the generated walkthrough path to: 1. Open https://josephniemchak.com/mynd. 2. Open [[Use Joe's Mynd]]. 3. Follow the well-being path to [[Start By How You Feel]]. 4. Choose one feeling path. 5. Open one recommended practice. 6. Try one gentle attempt. 7. Ask [[Did This Help]]. 8. Choose one tiny result: easier, harder, or about the same. 9. Ask the smallest fit check: did it fit right, fit wrong, or is it too early to tell? 10. Use the prefilled feedback link. 11. Confirm the feedback form carries the state, practice, source, path, result, and fit context. 12. Preview the closed loop without submitting. 13. Confirm the preview says the loop is closed, no feedback was sent, and stopping is allowed. 14. Open the sample ready-state feedback review: https://josephniemchak.com/feedback-report?preview=sample-ready. 15. Confirm the sample says no feedback was sent or fetched, then shows signal readiness, a recommended decision, and one bounded next action. 16. Do not submit private, clinical, crisis, or identifying details. The release is not done until the public path works for a person, not only for a script. ## Source Of Meaning This note comes from the recursive UX work that added local, flow, live, publish, predeploy, and postdeploy readiness gates for Joe's Mynd. ## Relationship Over Time This path should change when the public Mynd release process changes. If the live site is behind local, the next action is deploy/sync with explicit approval, not more local proof. If the scripts pass but the browser path feels confusing, the next action is a UX revision. ## Links - [[Codex To Obsidian Loop]] - [[For Agents]] - [[Obsidian Publish Plan]] - [[Public Private Boundary]] - [[Use Joe's Mynd]] - [[Start By How You Feel]] - [[Practice Fit Map]] - [[Practice Result Loop]] - [[Mynd Feedback Loop]] - [[Did This Help]] ## Tensions A release process can become performative if it only proves files changed. The real goal is a public Mynd that a person can enter, understand, use, and respond to safely. ## Question Is the local Mynd ready, is live current, and can a person complete the path?