The snippets, ordered obscure → unmistakable

  1. Snippet 1(Generic memory helper)
  2. Snippet 2(Internal mutex shim)
  3. Snippet 3(Public C API surface)
  4. Snippet 4(BTREE flag wash)
  5. Snippet 5(VDBE opcode dispatch)
  6. Snippet 6(Header banner — every .c file)

Why this project gives itself away

The give-away. Snippet 1 looks like any C codebase, but the sqlite3 prefix is already a tell — every internal symbol in the project is namespaced sqlite3*. Snippet 2 hints at the single-file amalgamation by referencing sqlite3GlobalConfig. Snippet 3 is the public API — sqlite3_prepare_v2 is one of the most famous C functions in software. Snippet 4 surfaces BTREE_INTKEY and the project's B-tree storage layer. Snippet 5 is the unmistakable VDBE virtual-machine opcode dispatch (OP_OpenRead/OP_OpenWrite); SQLite compiles SQL to a bytecode it then interprets. Snippet 6 is the blessing D. Richard Hipp puts in every file header in lieu of a copyright notice — Framed-defining.

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.

↳ The blessing is famous; see https://sqlite.org/copyright.html