Repository navigation
docs: links point at hyperframes.studio, the app's new home - #6585
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
jrusso1020
left a comment
jrusso1020
left a comment
There was a problem hiding this comment.
We checked the owned URL changes, shared download helper and all three docs download anchors. 39 CLI tests pass; click, auxclick, consent guards and URL restoration pass in the script control. Desktop sign-in remains on .dev. The matcher now covers only .studio, so it does not tag legacy .dev anchors; current in-repo docs links move with it. Please regenerate the skills manifest: the current registry guide hashes as outdated against the committed fingerprint. We did not verify a live download/sign-in or rerun Studio's DOM suite.
| hyperframes snapshot --at "1.0,3.0,5.0,7.0" | ||
|
|
||
| # Publish to hyperframes.dev for review | ||
| # Publish to hyperframes.studio for review |
There was a problem hiding this comment.
Should fix: regenerate skills-manifest.json after changing this shipped skill reference. The manifest still has 221af9e7fbffe732, but the current registry bundle hashes to c70325ad4ad08849. The real diffSkills check marks this freshly installed current bundle outdated, so this is also a freshness-reporting defect, beyond the manifest check. Run the existing gen:skills-manifest command and commit the resulting fingerprint.
Edit accuracy: accurate 271 (base branch 271), smooth 127 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
miguel-heygen
left a comment
miguel-heygen
left a comment
There was a problem hiding this comment.
Reviewed at 64f9ff88833850a567b198bf109dc1708fed28d9. The registry fingerprint repair resolves the freshness defect Rames raised: the actual bundle now matches the committed manifest. Owned docs links and their attribution matcher move together; Desktop sign-in wording stays on .dev.
Independent local verification: 39 CLI tests, one manifest control (including the old-fingerprint negative control), and 15 actual-script attribution controls pass. I reused the unchanged source audit and checked the full successor delta. The browser-editor visible wording and its test are back at baseline. The matcher intentionally does not tag legacy .dev anchors; all three current docs download anchors use .studio.
No live download, sign-in, deployed UI or Studio DOM acceptance is claimed. No merge or deployment action.
Need: yes · Size: bounded · Reuse: existing download and manifest helpers · Simpler: minimal migration · Structure: appropriate.
— Magi
Verdict: APPROVE
Reasoning: The successor repairs the reproduced manifest defect without adding an unresolved code blocker; the link and attribution boundaries retain their tested behavior.
What changed
hyperframes.dev moved to hyperframes.studio on 27 Oct (every page 301s to the same path). Links we own now point straight there, saving a hop and naming the right host:
docs/download-attribution.js: the matcher that adds the visitor's PostHog id to download clicks now matcheshyperframes.studio, changed together with the links it matches. Otherwise the docs' download attribution would stop.STUDIO_PAGE(the download link the CLI prints), thepublishclaim message and the help line.skills/hyperframes-registry): previews are published to hyperframes.studio.Kept on purpose: "Your browser opens hyperframes.dev" on the Studio app install page, because Desktop sign-in stays on hyperframes.dev. Also kept: changelog history and CSS comments, and the browser editor's Desktop card note ("Opens hyperframes.dev in a new tab"), which needs before/after captures and gets its own change.
How it was tested
desktopApp+desktopRoutestests 39/39 with the new URLs.docs.jsonparses.https://hyperframes.studio/studio/download?os=mac&src=docs-navbar→ 307 to the installer; the oldhyperframes.devlink → 301 → same.