Field notebook · Format study · WEB-FABLE-W1

TinkerPages

A documentation format — one project, one page — for makers whose finished projects live undocumented in drawers and photo rolls.

In Design DOMAIN HELD — tinkerpages.com
The idea

One project, one page.

Finished projects die undocumented. The build works, the maker moves on — and everything that made it work scatters: the parts list into an old email, the wiring shot into a camera roll, the one crucial fix into nobody’s memory.

Six months later the project might as well not exist. It can’t be repaired, reproduced, shown, or learned from. It sits in a drawer, complete and mute. That failure is not a motivation problem; it’s a format problem. Documentation fails when it is open-ended — a blog post can be any length, so it never gets started.

TinkerPages proposes a discipline instead of a platform: every finished project gets exactly one page, and that page has required blocks. Fill the blocks and stop. The page is done when the blocks are done — which means it actually gets done.

The format is the product. Everything else on this page is styling around that one claim.

Format spec · v0

Seven required blocks

PROPOSAL  This block list was drafted in this design wave (WEB-FABLE-W1, 2026). It has not yet been tested against real projects — that test is the stated next step, not a formality.

  1. 01 TITLE The project’s name. No cleverness required — findable beats witty.
  2. 02 ONE-LINE WHAT One sentence a stranger could understand without seeing the project.
  3. 03 PARTS / INPUTS Everything the build consumed — materials, tools, software, files.
  4. 04 STEPS The shortest honest path from nothing to done. Not a tutorial — a record.
  5. 05 WHAT BROKE The failures, in order. The block most write-ups omit and the one worth the most.
  6. 06 RESULT What exists now, stated plainly. No adjectives needed.
  7. 07 NEXT TIME The one thing the builder would change. The lesson, before it evaporates.
Signature piece · Live demonstrator

Watch the format carry the weight

Example TinkerPage built from a real Curiosell artifact.

Below is a TinkerPage written for the Landing Pad Pack procedural generator — a real SketchUp/Ruby generator, part of DRONIEUS, that was used to produce a real asset pack. Use the format spec panel to switch required blocks off and on. Each removed block leaves a hole the page can’t hide, and the completeness meter reads what remains. That is the argument: the format, not the styling, is what makes a project survive.

The panel’s toggles and meter are real controls computing this page’s live state — nothing here is simulated data. Two blocks of the example are honestly unfilled; the page says so where it happens.

Printing strips the notebook — tape, tilt, grid, panel — and outputs only the example above as one clean page, in whatever toggle state you leave it. “One project, one page,” made literal. The marker pass overlays an editor’s red pen on the example — margin remarks grading the page against the spec, each one repeating a fact the document already states. The pen never reaches paper: printing strips it with the rest of the costume.

Format spec panel

Toggle blocks 03–07 to see what the page loses. Blocks 01 and 02 are locked — a page without a title and a one-liner isn’t a page. Number keys 3–7 toggle them from anywhere on the page (outside text fields).

01 TITLE LOCKED
02 ONE-LINE WHAT LOCKED

Completeness meter

Gauge showing how many of the seven required blocks are present. DRAWER DOCUMENTED
7 / 7 blocks present
Filled on this example: 5 / 7 — 2 blocks await the builder’s memory.

COMPLETE — all seven blocks present. This is the shape of a finished TinkerPage.

The meter reads the demo’s actual toggle state, computed live on this page. It is a design instrument, not product telemetry.

TINKERPAGE · EXAMPLE · 2026 WORKING
01 TITLE

Landing Pad Pack — procedural generator

02 ONE-LINE WHAT

A parametric Ruby script for SketchUp that generates drone landing-pad geometry and markings at chosen sizes.

03 PARTS / INPUTS
  • SketchUp, as the host application (the script runs on its Ruby API).
  • One parametric Ruby script — the generator itself.
  • Size parameters, chosen at run time, that set the pad geometry and markings.
  • No hand-modeled assets: the geometry is generated, not imported.
04 STEPS
  1. Load the Ruby script into SketchUp.
  2. Choose the pad size parameters.
  3. Run the generator — it builds the pad geometry and its markings.
  4. Save the output as a SketchUp model.
  5. Re-run at other sizes as needed. Parametric means regenerable: the pack is a script’s output, not a frozen mesh.
05 WHAT BROKE UNFILLED — needs the builder

Not yet written. This block needs the builder’s own failure log, and no failure record was pulled for this example — inventing one would break the page’s rules. Worth noticing: WHAT BROKE is the first block to die when documentation waits, and the reason this format makes it required.

06 RESULT

The generator was used to produce a real asset pack — the Landing Pad Pack, part of the DRONIEUS product surface. The pack exists, and because the generator is parametric, it can reproduce the pack — and variants of it — on demand.

07 NEXT TIME UNFILLED — needs the builder

Not recorded. A real TinkerPage closes with the one line its builder wishes they’d known at the start. This example is waiting on that line rather than faking it.

SOURCE ARTIFACT: a real SketchUp/Ruby procedural generator, part of DRONIEUS (dronieus.com, referenced as text only). Details above stay generic-but-true; two blocks are honestly unfilled pending the builder’s notes.
This week’s bench · 2026-07-09 · DEMO CONTENT

What to tinker with this week

  • Poke at the stateless MCP release candidate. The Model Context Protocol’s 2026-07-28 spec drops sticky sessions — a remote tool server can run behind a plain load balancer. Small experiment: stand up a minimal MCP server, watch what an agent actually requests. Spec RC announcement (official blog).
  • Scaffold one agent as a directory. Vercel’s open-source eve framework treats an agent as a folder: markdown instructions plus TypeScript tools. Good weekend-sized probe of the “agents are files” idea. Ship 2026 recap (Vercel) · InfoQ coverage.
  • Race two CLI coding agents on the same chore. Terminal agents (Claude Code, Codex CLI, Gemini CLI) differ most on approvals, sandboxing, and cost — visible only if you give them the identical task. DeployHQ comparison, 2026.
  • Re-price an agent workload. Claude Sonnet 5 (2026-06-30) is pitched as agent-grade at $2/$10 per million tokens introductory through 2026-08-31. Rerun an existing agent job and compare the bill, not the benchmark. Anthropic announcement.
Bench rules · verification

Safety / verification reminders

  1. Pin versions before a spec change lands. The MCP revision above has a formal deprecation policy — use it; don’t ride nightly. RULE
  2. Check claims against the primary source. Every card at left links its origin; aggregator summaries were discarded when this list was drafted. RULE
  3. Free tiers are promotional phases. Gemini CLI’s free tier reportedly ended in June 2026 — budget any tool you come to depend on. RULE
  4. Label demo content as demo content — the way this section does. RULE

PLACEHOLDER DISCLOSURE  This bench list is demo content added 2026-07-09 (WEB-LIVE-A1) so the page can be reviewed live. Items are short paraphrases of the linked external sources. No TinkerPages community, users, or submissions exist.

Honest scope

What TinkerPages is not

  • Not a blog. A TinkerPage is written once, when a project finishes, and then it is done. No feed, no cadence, no pressure to keep posting.
  • Not a community. No community, no users, and no submissions exist. Saying otherwise would be fiction, and this page doesn’t do fiction.
  • Not a product or a service. tinkerpages.com is a held domain. This page is a design study — status IN DESIGN — not a launch.
  • Not portfolio gloss. WHAT BROKE is a required block. A TinkerPage that only flatters its builder is malformed by definition.
Direction — stated as a plan

How it could grow

TinkerPages is content-gated by design: it grows only when real pages exist. The plan, phrased as a plan and nothing more:

  1. Write 3–5 real TinkerPages of real finished projects. The first candidates would come from Curiosell’s own artifacts, the way the worked example above does. PLANNED
  2. Test the seven-block spec against those pages and revise it where it fails. The spec is a proposal until real projects have pushed back on it. PLANNED
  3. Decide between a hosted gallery of TinkerPages and purely personal use. Undecided, and stated as undecided. CONCEPT

Until real pages exist, TinkerPages stays exactly what it is here: a format, demonstrated. It is a study by Curiosell Systems LLC — a one-person systems studio run by Alex Fraley, early stage, no meaningful sales yet, with nothing in this wave deployed.