Skip to content
alzy.kr
← Devlog

Every quality gate passed, and 5 minutes 43 seconds later I deleted it — the TAMNA board sky

The requirement was one line. "Make it feel alive." Implementation finished at 1:34 in the morning and every verification item passed. At 1:40 I deleted all of it.

Written: 2026-06-14

Last updated: 2026-08-21

It always starts with a one-line requirement: "make it feel alive" 💭

The board already had a sky.

The clouds only swayed in place, the gull was a fixture, and pressing the lighthouse did next to nothing.

So I filed a requirement: "I want a sky that feels a bit more alive!"

The problem? That requirement carried no acceptance criteria at all.

Feels alive — meaning what? Satisfied when? Failed on seeing what?

Nobody asked. I was the only stakeholder. 😅

One thirty-four in the morning, implementation done! 🌙

Three clouds, crossing on cycles of 34, 40 and 46 seconds.

When do all three line up again? Once every four hours and twenty minutes.

Opacity sat between 0.16 and 0.2, with both edges fading out gently.

Two gulls. Travel went on the parent element, wingbeat on the child element.

Split that way, the two animations never trespass on the cycle of the other.

Click the lighthouse and the beam sweeps once over 1.4 seconds, then dies.

Reduced-motion was handled too. Accessibility, perfect! 🥳

Pencil sketch of three clouds drifting at different speeds over hexagonal tiles, with two gulls crossing diagonally
Three clouds, three different cycles. The arrow lengths are the difference.

Control Quality: all green ✅

Here is the verification record I left in the commit.

tsc passed. lint passed. Cloud drift YES. Gulls 2. Lighthouse beam click spawn confirmed live.

Every item asking whether the deliverable was built to spec came back YES.

I even wrote "does not obstruct play" into the commit message.

I was the one who made that call. 😎

And then, 5 minutes 43 seconds later, rejected ⏱️

A different question was still open. Did I build the right thing?

I captured the moving screen across several frames and laid them side by side.

The gull did not read as a bird. 👀

At that size and that opacity, a line crossing the screen reads as a smudge.

The moment your eye stops to check whether something is stuck on the display, the effect has already failed.

Clouds were harmless over water, then covered resource icons and numbers once they reached the tiles.

The beam was worse. The board is a top-down projection; the beam alone was a side light.

Pencil sketch of four screen frames in a row, the same bird fading left to right until it reads as a smudge
Laid out side by side, it stopped being a bird and became a smudge.

"This does not feel right" 🙅

That was me, and the sentence is still sitting in the revert commit.

Implementation done 01:34:57. Revert 01:40:40.

Five minutes, forty-three seconds.

Two files, 131 lines removed and 2 added. Effectively a rollback to what was there before.

If I hesitated, the hesitation fit inside those 5 minutes and 43 seconds.

Not everything went, though.

The static lighthouse, the basalt reef and the sea ripple rings stayed. They sit outside the reading area.

Not scrapped, relocated 📦

I did not throw the motion away.

Harubang, clouds, sun and moon, a sailing boat — every living piece moved to the login screen.

The sun and moon there are not decoration. They track the real clock and refresh every minute.

Log in at night and you get a night sky.

The same asset is a defect on one screen and a feature on the other.

Pencil sketch contrasting a screen packed with information against an almost empty one holding only a horizon and a cloud
The same cloud means the opposite thing on a reading screen and a viewing screen.

The lesson: viewing screen, or reading screen? 💡

What I learned is simple.

Decide first whether a screen exists to be read or to be looked at.

On a reading screen unnecessary motion is noise. On a viewing screen it is art.

The login screen has no resources to count and no next square to find.

The board is the opposite. Tile numbers, road ownership, buildable spots — almost all of it is there to be read.

So I changed the order of the questions. I no longer start with whether to add it.

I define what the screen is for, and then I write the acceptance criteria.

Wrapping up 🏁

Technically flawless work can still fail the person using it. I felt that first-hand.

Control Quality asks whether you built it right. Validate Scope asks whether you built the right thing.

That night I cleared the first and failed the second.

From here on I separate the role of a feature from the role of a screen at design time.

Building a sky that actually breathes — attempt number two, here we go! ☁️✨

TAMNA