Design project API serves a stale snapshot while reporting success

Summary

The design-project file API (DesignSync: list_files / get_file) returns a snapshot of
the project frozen roughly a month in the past. Every call succeeds and returns a
self-consistent view — but that view does not reflect the project's current state, and does
not include edits made since the snapshot.

There is no error, no warning, and no timestamp movement to indicate this. A tool that
diffs the API against a local mirror concludes the two are in sync when they are not.

Expected: list_files / get_file reflect current project state; updatedAt advances
when the project changes.
Actual: both return a stale snapshot; updatedAt never moves.

Evidence

1. updatedAt is frozen, including across successful writes.
list_projects reported updatedAt: 2026-07-14T23:16:38Z. On 2026-08-14 I pushed 31
files via finalize_plan + write_files. Those writes landed — the paths now appear in
list_files and resolve via get_file. updatedAt did not change, and still reads
2026-07-14T23:16:38Z two days later.

2. get_file returns content older than a known ZIP export.
A ZIP export downloaded from the web UI on 2026-08-13 has a tokens/colors.css containing a
per-app accent block and a set of text-safe token steps. get_file on the same path returns
neither, and instead splits the light theme into two scopes the export does not have. The
API is serving a different, earlier revision of the file.

3. _ds_manifest.json is stale in a way consistent with the same date.
It lists 14 components, omitting 3 that exist in the project and in the export. It also
drops one token stylesheet from globalCssPaths and omits 3 preview cards. The 2026-08-14
write_files push added those paths to the file listing but did not cause the manifest to be
rebuilt.

4. Recent structural edits are entirely invisible.
On 2026-08-16 the project was restructured — a main page with navigation linking to a
detail page per component type. None of it appears: list_files returns no new paths, the
manifest shows no new cards or starting points, and get_file index.html returns
404 {"code":"not_found","message":"file not found"}.

Earlier form of the same bug

Before the 2026-08-14 push, the API omitted 31 files present in the 2026-08-13 ZIP
export — list_files skipped them, get_file 404d on each. Pushing those files up made the
listing agree. It did not fix the underlying staleness, and it removed the only outward
signal that anything was wrong. The bug went from loud to silent.

Reproduction

1. Open a design project; note updatedAt from list_projects.
2. Edit the project in the web UI — change a token value, add a page.
3. Call list_files and get_file on the edited paths.
4. Observe: updatedAt unchanged; new paths absent; get_file returns pre-edit content.
5. Optionally write_files to any path and repeat step 3 — the write shows up in

list_files, but updatedAt still does not move and the manifest is not rebuilt.

Impact

The ZIP export and the API disagree about project contents, and the export is the one
matching what was actually built.

Because the file listing is now complete, a structural diff between the API and a local
mirror comes back clean, which reads as "in sync." Acting on that would have deleted 25
per-app accent references and 24 text-safe token steps from our repository — consumed by 13
and 14 files respectively across shipping application themes — while silently reverting
several components to month-old revisions.

We caught it only because a file we knew had changed came back unchanged. A team trusting
the clean diff would not have.

We now sync exclusively from ZIP exports and treat the API's pull direction as unsafe.

Questions

1. Is the store behind list_files/get_file a separate, asynchronously-updated copy of the

project? If so, what triggers reconciliation, and can it be forced?

1. Is the frozen updatedAt the same defect or a separate one? It's the field a sync tool

would naturally use for change detection, and it is currently unusable for that.

1. Is a snapshot/export endpoint available or planned? The ZIP is currently the only channel

we trust, and it's web-UI only — so any automated sync needs a manual download step.

_{Project ID available privately on request.}