René's URL Explorer Experiment

Title: fix(cli,skill): let sync and publish share one baseline, and add an app-models reference by jamesbhobbs · Pull Request #508 · deepnote/deepnote · GitHub

Open Graph Title: fix(cli,skill): let sync and publish share one baseline, and add an app-models reference by jamesbhobbs · Pull Request #508 · deepnote/deepnote

X Title: fix(cli,skill): let sync and publish share one baseline, and add an app-models reference by jamesbhobbs · Pull Request #508 · deepnote/deepnote

Description: Two strands, both about the same confusion: which command owns a project's files, and which app model a given deliverable actually is. packages/ — sync and publish stop overwriting each other's writes to the project file store. skills/ — a canonical reference for Deepnote's app models, and a corrected skill sync map in AGENTS.md. deepnote static-site access — change a published site's sharing and viewer API access without republishing (section at the end). 1. Sync and publish share one baseline The conflict deepnote publish deploys into _deepnote_static/**, which is a subtree of the project file store that deepnote sync --all-files mirrors. Neither command knew the other existed — STATIC_ROOT was a private const in publish.ts, and sync claimed the entire inventory. Four consequences: Guaranteed churn. Publish never touched sync's manifest, so after every publish the whole static subtree looked changed and the next sync --all-files re-downloaded the built site into .files/. Push could regress a live site. uploadProjectFiles never fetched the inventory at all — it was documented "last-write-wins, no staleness check", with no equivalent of the baseModifiedAt/baseContentHash protection the notebook path gets. --prune produced ghosts. publish --prune removed a remote asset; sync's local copy still hash-matched the manifest so push skipped it, leaving it on disk forever and resurrecting it in the cloud on the next edit. Round-trip loop. dist/ → publish → cloud → sync pull → .files/ → git → sync push → cloud. The fix Coordination, not partition — both commands keep writing the same paths. Sync gains per-file lost-update protection on push. Every candidate is now checked against the cloud inventory, and a file that moved since the manifest baseline goes through the existing --on-conflict override-or-skip choice instead of being overwritten. Reported as N file(s) kept from Deepnote / filesSkipped. This is the load-bearing part: publish often runs from CI where no manifest exists, and the Deepnote app can write these paths too. It also fixes the same silent overwrite for ordinary working files (requirements.txt edited in the app was clobbered before). Publish updates the sync mirror when the published directory sits inside a synced workspace: it writes each file into the project's .files/ mirror and records size, hash, and server updatedAt, exactly as a sync download would. Manifest, mirror, and cloud then agree, so sync sees the deploy as already in step. --prune drops pruned paths from both. --sync-root