BetaMaShop is in public beta. We improve it continuously, and your feedback shapes what comes next.

Editing by hand

Your codeEnglish· 4 min read· Updated September 01, 2026

What you can change by hand and keep, which eleven files every generation rewrites, and why a workspace edit never reaches your live site.

Your code

Your code exists in two places at once: a working copy inside MaShop, and your GitHub repository. Netlify builds from the repository, never from the working copy.

That single fact decides where a hand edit is worth making.

Edits made in the workspace editor stay in the workspace

The Code view saves to MaShop. Ctrl+S writes to MaShop's own file table. Nothing is sent to GitHub: the panel exposes no push button, and the badge that would flag a gap between the two is fixed to false, so the interface cannot warn you.

Click Update afterwards and Netlify rebuilds from GitHub, where your change is not.

A hand edit made in the workspace can be lost for good

A manual save creates no version, and the next generation reloads your code from GitHub. An edit that never reached GitHub is overwritten at that moment, with nothing left to restore it from. Clone the repository, commit, push: Netlify and the next generation both read from there.

The eleven files every generation rewrites

At each generation, MaShop rewrites a fixed set of files in its build container, without asking:

  • apps/storefront/src/app/globals.css, the base stylesheet plus a palette specific to your project.
  • Six components of the public site: ProductRow, ProductSpotlight, ProductTile, ProductCell, Reveal, SmoothScroll.
  • Four identity files recopied from the template: src/lib/site.ts, components/Header.tsx, components/Footer.tsx, app/layout.tsx.

It also deletes apps/storefront/tailwind.config.ts.

On any generation after the first, your real code is pulled back from GitHub and laid on top of those rewrites. Your versions of globals.css, site.ts, Header, Footer and layout then win. MaShop's files win in two cases only: on the very first generation, and when reading GitHub fails while no generation has ever succeeded on the project.

What never reaches your repository

Only files under apps/, packages/ or supabase/ are committed. Everything written at the root of the repository is discarded before the commit.

That includes AI_RULES.md. The file is rewritten at every generation and dropped at every commit, so anything you write in it is never read back. Put lasting instructions in your prompt, not in that file.

Never committed either: node_modules, .mashop, .git, .claude, .next, .turbo, dist, package-lock.json, pnpm-lock.yaml, and any .tsbuildinfo.

What the AI can see of your work

Before an iteration, MaShop pulls your repository back into the container, with a ceiling: 1200 files at most, in at most 12 grouped writes. Files left out are reported, never cut silently.

When that budget is not enough, the order of priority is apps/storefront first, then root configuration and packages/, then supabase/, and apps/admin last. Heavy hand work inside the back office can therefore be invisible to the AI, and overwritten.

Binary files are never read back: .png, .jpg, .webp, .woff, .pdf, .zip and the like would be corrupted by the text conversion. .env files are excluded on purpose, so a secret pushed by mistake is never exposed to the model.

How a generation commits

The commit message is always feat: MaShop AI build. Before pushing, MaShop scans the files for hardcoded secrets and refuses the commit if it finds any.

At that same moment, template files missing from your repository are added, so a site that compiles at MaShop does not break at your end. Until a generation commits, your repository stays frozen at the template version of the day it was created, and nothing announces that it has aged.

Versions, and what a restore does

Only a successful generation creates a version. A manual save creates none, and a deployment creates none. A project worked on by hand shows a near empty timeline.

What a restore replaces, and what it leaves alone, is set out in Undo and restore. Two of its limits matter here. A restore never touches your database, so going back past the point where a table was created leaves code talking to a schema that has moved on. And it never updates your live site, which changes at the next Update.

Limits on the workspace copy

5 MB per file, 50 MB per request, 200 files per request. After a generation, the file tree sent back to the screen is capped at roughly 3 MB and the largest files are dropped from the display; the commit in your repository keeps everything.

editingworkflowgenerationgitversions
Was this page helpful?
Your feedback is anonymous.