[terencecho]

What

Change detection in @hyperframes/share keeps working when .hyperframesignore uses gitignore syntax. snapshotProject, snapshotFiles and projectFingerprint now fall back to scratch-only exclusions when the file can't be read. Source capture keeps the strict reader and still refuses the file.

Why

0.9.33 made the project scan read .hyperframesignore through the strict source reader. That reader accepts plain paths and a single *, and rejects anything else. Cloud render reads the same file as gitignore syntax, and the cloud docs use /exports/ as their example (docs/deploy/cloud.mdx).

With such a file, the scan throws SourceIgnoreError, so a host loses change detection, export freshness and share status for that project. /renders/, **/*.mov, !keep.mp4 and assets/*/raw-*.mp4 all throw; assets/big.mp4 and *.mov don't. 0.9.34 has the same reader.

How

readChangeIgnore(root) wraps readSourceIgnore and returns the scratch-only rule (*.log, *.swp) when the file can't be read. Both scan functions use it. A scan then sees more files, never fewer, so a change to a file the user meant to exclude still counts as a change, the safe direction for change detection. Source capture (sources/capture.mjs) still calls readSourceIgnore directly, so preparing source still fails with the existing error. The share-source doc now describes this.

Test plan

• New tests in kernel.test.mjs:
  • five gitignore-only rules leave scan, snapshotFiles and fingerprint working, and an edit still changes the fingerprint;
  • a symlinked ignore file doesn't throw;
  • a valid file still excludes its paths and *.log.
• The two new no-throw tests fail without the fix and pass with it.
• Share package suite: 133/133 on Node 22 and Node 26, including the existing source-capture tests that refuse invalid files.
• Share package typecheck, oxlint and oxfmt are clean. Pre-commit hooks pass.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
hyperframes	🟢 Ready	View Preview	Nov 11, 2026, 7:03 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[jrusso1020]

Reviewed at b5c4245971a88cdd21565a392182b3438e81ea4a.

Both scan entry points use the fallback, and projectFingerprint inherits it. sourceIgnore.mjs:70 reuses the strict reader and scratch predicate; sources/capture.mjs:87 still calls the strict reader directly. Existing hidden/app-owned exclusions remain applied independently. No blocker found.

Nit: packages/share/tests/kernel.test.mjs:663: assert .get("assets/clip.mov") !== undefined instead of .has(...). snapshotFiles sets every requested key, including excluded files, so key presence alone does not prove tracking.

Validation: bun run build passed; Node 24 node --test packages/share/tests/*.test.mjs passed 133/133, including invalid-ignore source-capture rejection. With only projectSnapshot.mjs restored to the previous implementation, both new no-throw tests failed with invalid_source_ignore. Reviewed sources restored afterwards. No live Desktop run.

Need: yes, restore scans for existing ignore syntax · Size: ok · Reuse: strict reader and scratch predicate · Simpler: already minimal wrapper · Structure: fine (checked snapshotProject, snapshotFiles and captureProject; no split)
Risk: low — localized scan fallback; source capture remains strict.

Verdict: APPROVE
Reasoning: Invalid ignore configuration no longer disables change detection, while source preparation preserves its existing rejection behavior.

— Rames

[github-actions]

Edit accuracy did not run: 0 of 15 shards reported results; see the shard jobs.

Nothing was compared with the base branch.

[terencecho]

Addressed the nit in 5cee45f: the gitignore-syntax test now asserts snapshotFiles(...).get("assets/clip.mov") !== undefined. Confirmed the premise: for a file excluded by a valid ignore rule, snapshotFiles returns has = true but get = undefined, so the old check couldn't tell the two apart. Share suite: 133/133.

[jrusso1020]

Reviewed at 5cee45f6ff92a83bf414d9fa13ebb15d81d8954d.

Read the complete delta from my prior approved head b5c42459: only the targeted test assertion and its explanation changed. The assertion now checks a defined snapshot value, resolving my nit. No production changes or new findings. Prior build and 133-test results apply to b5c42459; I did not rerun tests for this assertion-only delta.

Need: yes, strengthen regression coverage · Size: ok · Reuse: existing snapshotFiles contract · Simpler: already minimal · Structure: fine (checked snapshotFiles undefined sentinel; no split)
Risk: low — test assertion only.

Verdict: APPROVE
Reasoning: The test now proves the requested file is tracked rather than merely named; the previously reviewed runtime fix is unchanged.

— Rames