Checklist the per-video bar — engine/sim
98.0/100
quantitative quality · weights learn from your reviews (
engine.sim.memory review longform-W28-Wed good|bad)⚠ 1 flag(s) — not yet ship-ready: copy_generic · see docs/strategy/VIDEO-CHECKLIST.md
Composition comp · template family · expected output
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 6 scenes · 146.2s · comp_id + rendered still + tier + the script
| # | Layer (comp_id · still · tier) | Beat | Timecode | Motion | Logo | Audio | VO / on-screen / caption |
|---|---|---|---|---|---|---|---|
| 1 |  matches intent shared field signature-3d | open | 0–23.4s | spatial-parallax | icon·white-knockout | ♪ bed_in | The moment the hub went live, it became a target. Every public site gets poked by bots within hours. That is not scary, it is normal, and there are plain moves to handle it. Today I show you how we keep the The Big T-M hub safe, and how you can lock down your own site without a security badge or a panic attack. on-screen: A live site is a target |
expected on screen: red ground · icosa hero in the shared Signal Field · Signum leads · node-graph · spatial-parallax · icon·white-knockout logo · caption bottom-left spec (the prompt): comp_id shared Signal Fieldvisual node-graphshape icosaground redtreatment white-knockoutmotion spatial-parallaxpower summoninstrument summon→A live site is a target | |||||||
| 2 |  matches intent NumberedList template | teach | 23.4–47.9s | kinetic-build | icon·white-knockout | ♪ node_lock | First move. Your API keys and passwords must never sit inside your code files. We keep ours in a separate secrets file that is never uploaded, and the code reads them from the environment at run time. Before any push, we run a quick scan for leaked keys. A key in your public code is a door left open. We close it before anyone tests the handle. on-screen: Get your secrets out of the code |
expected on screen: red ground · a NumberedList panel over a dimmed Signal Field · Signum leads · node-graph · kinetic-build · icon·white-knockout logo · caption bottom-left spec (the prompt): comp_id NumberedListvisual node-graphshape icosaground redtreatment white-knockoutmotion kinetic-buildpower morphinstrument morph+laser→Get your secrets out of the codecurate items, nodes | |||||||
| 3 |  matches intent ChecklistCard template | teach | 47.9–72.4s | kinetic-build | icon·liquid-chrome | ♪ node_lock | Second move. Every page on the hub is served over HTTPS, the locked-up version of web traffic, so nobody between you and the visitor can read or change what is sent. Modern hosts give you this for free, but you have to turn it on and force it, so a plain unlocked address bounces to the locked one. We set that redirect and tested it by hand. on-screen: Force every page to HTTPS |
expected on screen: red ground · a ChecklistCard panel over a dimmed Signal Field · Signum leads · node-graph · kinetic-build · icon·liquid-chrome logo · caption bottom-left spec (the prompt): comp_id ChecklistCardvisual node-graphshape icosaground redtreatment liquid-chromemotion kinetic-buildpower morphinstrument morph+laser→Force every page to HTTPScurate items, nodes | |||||||
| 4 |  matches intent BuildLog template | teach | 72.4–98.30000000000001s | kinetic-build | icon·white-knockout | ♪ node_lock | Third move. Most of any site is borrowed code, the packages you pulled in. Old packages have known holes that bots hunt for. We run an audit command that lists every package with a known weakness, then update them. We had the model do this and re-run the tests after, so a security fix does not quietly break the site. You patch the parts you did not write, on a schedule. on-screen: Patch what you did not write |
expected on screen: red ground · a BuildLog panel over a dimmed Signal Field · Signum leads · node-graph · kinetic-build · icon·white-knockout logo · caption bottom-left spec (the prompt): comp_id BuildLogvisual node-graphshape icosaground redtreatment white-knockoutmotion kinetic-buildpower morphinstrument morph+laser→Patch what you did not writecurate lines, nodes | |||||||
| 5 |  matches intent RankList template | proof | 98.3–119.9s | receipts-count | icon·liquid-chrome | ♪ node_lock | The proof. Before launch, the hub went through this exact checklist. No keys in the code, locked traffic on every page, every borrowed package audited and clean. We did not write a guide about security and skip it ourselves. The live site you can visit passed the audit we just described, and that is the only proof worth showing. on-screen: The hub passed its own audit |
expected on screen: red ground · a RankList panel over a dimmed Signal Field · Signum leads · receipts · receipts-count · icon·liquid-chrome logo · caption bottom-left spec (the prompt): comp_id RankListvisual receiptsshape icosaground redtreatment liquid-chromemotion receipts-countpower receiptsinstrument spotlight→The hub passed its own auditcurate rows, statsLabels | |||||||
| 6 |  matches intent shared field signature-3d | resolve | 119.9–146.20000000000002s | coalescence | icon·white-knockout | ♪ bed_out | That is how The Big T-M keeps the hub locked. The takeaway is three habits. Keep secrets out of your code, force HTTPS everywhere, and audit your packages on a schedule. None of it needs a specialist, just the discipline to do it. Your next step. Run a key scan and a package audit on your own site this week. Then see the result of ours at office dot temerarii dot xyz. on-screen: Run the three checks today |
expected on screen: red ground · icosa hero in the shared Signal Field · Signum leads · coalescence · coalescence · icon·white-knockout logo · caption bottom-left spec (the prompt): comp_id shared Signal Fieldvisual coalescenceshape icosaground redtreatment white-knockoutmotion coalescencepower coalescenceinstrument coalescence→Run the three checks today | |||||||
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)
youtubeLock Down a Live Site: Hide Secrets, Force HTTPS, and Audit Your Packages
The moment a site goes live it becomes a target. Bots poke every public site within hours. That is normal, and there are plain moves to handle it. This walkthrough shows how to lock down your own site without a security badge or a panic attack.
The three habits:
- Get your secrets out of the code. API keys and passwords must never sit inside your code files. Keep them in a separate secrets file that is never uploaded, read at run time, and scan for leaked keys before any push. A key in public code is a door left open.
- Force every page to HTTPS. HTTPS is the locked-up version of web traffic, so nobody in between can read or change what is sent. Modern hosts give it free, but you have to turn it on and force it, so a plain unlocked address bounces to the locked one.
- Patch what you did not write. Most of any site is borrowed code, the packages you pulled in. Old packages have known holes bots hunt for. Run an audit command that lists weak packages, update them, and re-run your tests so a security fix does not quietly break the site.
The proof: before launch the hub went through this exact checklist, no keys in the code, locked traffic on every page, every borrowed package audited and clean. We do not write a guide about security and skip it ourselves.
Your next step: run a key scan and a package audit on your own site this week. See the result at office.temerarii.xyz.
Keywords: web security, HTTPS, secrets management, dependency audit, npm audit, site hardening.