Back Office · office.temerarii.xyz
One asset, all the way in — composition, the wireframe + storyboard, the output format stack, and the template, all read from the SAME content-index record. The expected output matches what /media surfaces for this post.
post longform-W28-Monkind longformweek W28date 2026-07-13campaign longform-youtubepillar it_devbeat —asset videoduration 156.2sground whitescenes 7

Checklist the per-video bar — engine/sim

100.0/100
plain languagevo coverageno dead airuniquenesscaption fitcompletenesscleanliness
quantitative quality · weights learn from your reviews (engine.sim.memory review longform-W28-Mon good|bad)
✓ all static checks pass — one-focal/scene · tier-by-beat · one-track caption · colorway · cast+shape correct · no banned/fabricated. (audio + visual tiers verify on the rendered finals — Phase 2)

Composition comp · template family · expected output

composition LongFormChaptersfamily / template LongFormChapters
9:16 Reelpending1:1 Squarepending16:9 Widepending9:16 4Kpending1:1 4Kpending16:9 4KpendingGIF (SMS)pending
render pending — silent master not yet on disk
expected output: 0/7 rendered — same matrix the /media preview surfaces for this asset.

Composition layer × scene 7 scenes · 156.2s · comp_id + rendered still + tier + the script

#Layer (comp_id · still · tier)BeatTimecodeMotionLogoAudioVO / on-screen / caption
1s1
matches intent
shared field
signature-3d		open0–25.2sspatial-parallaxicon·ember-fill♪ bed_in
The hub went live, and a live site is more than pretty pages. There is software running underneath it. Today we open that part. I will show you how we build custom software for the hub the same way you could build a small tool for your own business, without a giant team. You will learn how to go from an idea to working code you can actually trust.
on-screen: Software behind the live hub
expected on screen: white ground · box hero in the shared Signal Field · Faber leads · node-graph · spatial-parallax · icon·ember-fill logo · caption bottom-left
spec (the prompt): comp_id shared Signal Fieldvisual node-graphshape boxground whitetreatment ember-fillmotion spatial-parallaxpower summoninstrument summon→Software behind the live hub
2s2
matches intent
NumberedList
template		teach25.2–49.7skinetic-buildicon·wireframe♪ node_lock
First move. We do not start typing code. We write a short spec in plain words. What does this tool do, what goes in, what comes out, what must never happen. We hand that spec to Claude Code in the terminal. Now the model and you agree on the job before a single function exists. Most broken software comes from skipping this. We do not skip it.
on-screen: Write the spec before the code
expected on screen: white ground · a NumberedList panel over a dimmed Signal Field · Faber leads · node-graph · kinetic-build · icon·wireframe logo · caption bottom-left
spec (the prompt): comp_id NumberedListvisual node-graphshape boxground whitetreatment wireframemotion kinetic-buildpower morphinstrument morph+laser→Write the spec before the codecurate items, nodes
3s3
matches intent
ChecklistCard
template		teach49.7–75.6skinetic-buildicon·wireframe♪ node_lock
Second move. From the spec, the model writes the first version of the code. It is a coding agent, so it creates the files, fills in the functions, and explains what each part does. You read it like a draft, not a finished thing. Your job is to catch what is wrong, not to type every bracket. The blank page is the hardest part, and the machine handles the blank page.
on-screen: Let the model write the first draft
expected on screen: white ground · a ChecklistCard panel over a dimmed Signal Field · Faber leads · node-graph · kinetic-build · icon·wireframe logo · caption bottom-left
spec (the prompt): comp_id ChecklistCardvisual node-graphshape boxground whitetreatment wireframemotion kinetic-buildpower morphinstrument morph+laser→Let the model write the first draftcurate items, nodes
4s4
matches intent
LogStream
template		teach75.6–100.8skinetic-buildicon·wireframe♪ node_lock
Third move. Before we trust any tool, we ask the model to write tests for it. Small checks that feed in known input and confirm the right output comes back. We run them. Green means it works. Red means fix it now, not in front of a customer. When you change the code later, you run the tests again. That is how you change software without holding your breath.
on-screen: Tests are how you sleep
expected on screen: white ground · a LogStream panel over a dimmed Signal Field · Faber leads · node-graph · kinetic-build · icon·wireframe logo · caption bottom-left
spec (the prompt): comp_id LogStreamvisual node-graphshape boxground whitetreatment wireframemotion kinetic-buildpower morphinstrument morph+laser→Tests are how you sleepcurate nodes, rows
5s5
matches intent
PipelineMap
template		teach100.8–124.9skinetic-buildicon·wireframe♪ node_lock
The proof is not a promise. The software that powers the hub passes its own tests and is running live right now. We did not describe a tool we might build. We built it, checked it with the tests in front of us, and put it under the site you can visit. No made-up speed claims. It either runs or it does not, and it runs.
on-screen: It runs because we ran it
expected on screen: white ground · a PipelineMap panel over a dimmed Signal Field · Faber leads · node-graph · kinetic-build · icon·wireframe logo · caption bottom-left
spec (the prompt): comp_id PipelineMapvisual node-graphshape boxground whitetreatment wireframemotion kinetic-buildpower morphinstrument morph+laser→It runs because we ran itcurate nodes, stages
6s6
matches intent
ComparisonTable
template		proof124.9–151.20000000000002sreceipts-counticon·wireframe♪ node_lock
That is how The Big T-M builds software, given away straight. The takeaway. Write the job down first, let the model draft it, and never ship without tests that prove it works. Your next step is easy. Go to office dot temerarii dot xyz, use the hub, and know that everything responding under it was built with these exact moves. Then write one spec for the smallest tool you wish you had.
on-screen: See the working tool
expected on screen: white ground · a ComparisonTable panel over a dimmed Signal Field · Faber leads · receipts · receipts-count · icon·wireframe logo · caption bottom-left
spec (the prompt): comp_id ComparisonTablevisual receiptsshape boxground whitetreatment wireframemotion receipts-countpower receiptsinstrument spotlight→See the working toolcurate colA, colB, rows, statsLabels
7s7
matches intent
shared field
signature-3d		resolve151.2–156.2scoalescenceicon·ember-fill♪ bed_out
The machine: how we run a studio on AI, in public
on-screen: Chapter 6
expected on screen: white ground · box hero in the shared Signal Field · Faber leads · coalescence · coalescence · icon·ember-fill logo · caption bottom-left
spec (the prompt): comp_id shared Signal Fieldvisual coalescenceshape boxground whitetreatment ember-fillmotion coalescencepower coalescenceinstrument coalescence→Chapter 6

Format stack 1 aspects · same scenes[], re-cropped

16:9
1920×1080
X/Twitter · YouTube · LinkedIn video

Channels 2 destinations

YouTubeBlog

Social captions supplemental published copy · per channel (comp_id level)

youtubeBuild Custom Software for Your Business: Spec First, Model Drafts, Tests Prove It A live site is more than pretty pages, there is software running underneath. This walkthrough shows how to build a custom tool the same way you could build one for your own business, without a giant team. Idea to working code you can actually trust. The method: - Write the spec before the code. In plain words: what does this tool do, what goes in, what comes out, what must never happen. Hand that to a coding agent in the terminal. The model and you agree on the job before a single function exists. Most broken software skips this. - Let the model write the first draft. It creates the files, fills in the functions, and explains each part. You read it like a draft and catch what is wrong, you do not type every bracket. The blank page is the hardest part, and the machine handles the blank page. - Tests are how you sleep. Ask the model to write small checks that feed known input and confirm the right output. Green means it works, red means fix it now, not in front of a customer. Run them again whenever you change the code. The proof is not a promise. The software passes its own tests and runs live. No made-up speed claims, it either runs or it does not. Your next step: write one spec for the smallest tool you wish you had. See the working hub at office.temerarii.xyz. Keywords: custom software, spec-driven development, coding agent, automated tests, build vs buy, small business tools.

Cross-links every lens is a view on this one record

→ Wireframe · scenes→ Calendar week→ Media (audience preview)→ Storyboard hub→ Day view→ Channel view