We brought back HyperCard's stack, not its editor

2026-11-10来源 dev.to WebDevEnglish

Written as part of the Kiroween 2026 hackathon. The project is Stackyard: https://github.com/chainwright/stackyard

In 1987 a teacher who couldn't code could open HyperCard on Sunday night and make a clickable stack of cards for Monday's lesson. What she ended up with was a stack she could hand to someone else. That part is what I missed most when we looked at today's tools. Quiz platforms keep the quiz on their own site, usually behind accounts and a connection. A chatbot will write you an HTML quiz, but there's no editor inside it. Plenty of HyperCard revivals bring back the editor. We wanted the stack back.

Stackyard is what came out of it. A teacher types one sentence, something like "a 6-question quiz on the water cycle for 4th class, two flash cards and a short choose-your-path story about a raindrop", and the cards are dealt as the model writes them. She can fix anything HyperCard-style, then export one HTML file. The class opens that file in a browser with no account, no install and no internet. The file also edits itself: a small Teacher tab inside it saves a new copy that can do the same.

We built it with Kiro over about ten days. Below is what actually changed the way we worked, and where it didn't help.

Arguing with the spec before there was any code

I expected the specs to be paperwork. They turned out to be the place where most of the real decisions happened. Kiro wrote requirements, design and tasks for each of the five features from a plain chat request, and we reviewed them like pull requests and sent them back. The class-results spec changed twice on serious problems before a single line of it existed. Fixing those in prose took minutes. In code it would have taken days.

One requirement set the whole architecture, and it's worth quoting because everything else hangs off it: the exported file inlines every asset and "shall load nothing from the network at runtime". After that, every argument about a feature started with "does this survive offline?"

We also kept the specs honest with a small script. Every lettered task id has to show up in a test title, a gate or a hook. When the hackathon build was done, all 176 did. Before we had that script, the count was quietly drifting.

Hooks that run the real thing

The hook I'd copy into any project is what we call the living-file gate. On save it exports a lesson, edits it through the Teacher tab, saves a copy, and replays the copy with the network blocked. It's slow by hook standards, and it caught regressions that unit tests never would. Across 5–9 November the session store recorded 493 hook firings, mostly the cheap after-shell-command check that re-validates the stack invariants whenever Kiro writes files through the shell.

A reviewer that found our own bug

We wrote one custom agent, lesson-checker. It's a read-only reviewer that reads a deck the way you'd check content for 8–10-year-olds. Its best moment was an ambiguous Vikings question that one of our own fixes had introduced. We'd stopped seeing it; it hadn't.

Where tests lied to us

This is the part I'd tell another entrant first. We had 113 green tests and still shipped a defect: fallback ids that weren't valid UUID v4. A 30-second live run caught it. All our jsdom tests were green while real Chrome showed five problems, including a stamp that never appeared. And the living file worked locally and failed on the deploy, because the host's build skipped one bundle.

None of these were found by writing more tests in the same place. They were found by running the actual thing: a live run, a real browser, a real deploy. After that we made it a rule that every review happens in a real browser. Each failure also went back into the spec as a new invariant or a new gate, so it couldn't come back quietly.

To keep ourselves honest about the tests themselves, we wrote a script that reverts 118 of our review fixes one at a time and demands that something goes red. In the last logged run, all 118 were caught. That number made me trust the suite more than the test count ever did.

What I'd do differently

I'd write the "runs in a real browser" gate on day one, not day five. And I'd keep fewer, sharper steering files: ours grew to six, and the two that mattered most were the stack format and the audience.

Try it

If you teach and try it with a class, I'd really like to hear what broke.

Roman Pryvrotskyi, AutoMate AI

原文：https://www.a8q9.cn/en/article/we-brought-back-hypercard-s-stack-not-its-editor-39829b.html

相关文章