The snippets, ordered obscure → unmistakable
- Snippet 1(Store contract)
- Snippet 2(Component script)
- Snippet 3(Each block)
- Snippet 4(Compiled output)
- Snippet 5(Runes (Svelte 5))
- Snippet 6(compiler entry — svelte/compiler)
Why this project gives itself away
The give-away. Snippet 1's tiny writable store is Svelte's reactivity primitive — minimal and self-contained. Snippet 2's $: doubled = count * 2 reactive declaration is Svelte 3/4's signature. Snippet 3's {#each ... as item, i (item.id)} keyed-each block is unmistakable Svelte template syntax. Snippet 4 is compiled Svelte output — Svelte famously compiles components to surgical c()/m()/p()/d() lifecycle hooks instead of using a virtual DOM. Snippet 5 reveals runes ($state, $derived, $effect) — Svelte 5's new reactivity. Snippet 6 names the project ("cybernetically enhanced web apps" — Svelte's tagline).
How a Framed puzzle is built
Every Framed project ships exactly six snippets, hand-ordered from deeply obscure to unmistakable. The first snippet must be plausible for a dozen codebases — a generic loop, a small utility, a comment that could appear anywhere. The last snippet carries a project-specific tell: a function name, a code-comment idiom, a file header, a build invocation. Between them sit four snippets that gradually narrow the field. Reading them in order is half the puzzle: a returning Framed player learns to triangulate on indentation conventions, comment voice, naming, and the small-but-distinctive choices that betray a project's era and community.