Stickbash content engine + Studio (design)

Date: 6 Nov 2026. Owner: ENGINE (a lane under basha-21, the LIVE coordinator). Status: APPROVED by the user, 6 Nov 2026. All 15 decisions are made (D14 and D15 by the coordinator as technical calls). The four [call]s stand. The implementation plan is docs/superpowers/plans/2026-11-06-content-engine.md.

Marks: [user] = the user decided (6 Nov); [call] = my call, open to the user's veto; [ask] = it was in the decision list at the end, and every one is now DECIDED.

Code citations are file:line in the game repo StickFight-online-train7 (branch live-v4train7, StickBrawl/Assets/_Game/Scripts/..., shortened to Scripts/...) and in this repo (server/...).

This changes one earlier non-goal: the 28 Oct live-game design said "Downloadable content packs. Content ships in app updates (§14.4), but the catalog stays ready for them" (docs/superpowers/specs/2026-10-28-live-game-design.md:46). From now on new content is pushed from our server.

Summary for the founder (one page)

What we are building. One engine inside the game that plays new content from our server with no app update: maps, kill films, skins (with everything attached to them) and taunts / emotes. It is a fixed set of building blocks shipped in the app, about 50 that copy what the game does today plus about 61 new ones the game has never had. These include moving and spinning platforms, switches and doors, portals, lasers, saws, crushers, spawners, rising water and lava, weather, new camera moves, new skin materials and reactions, and taunt props. New items are designs that combine those blocks. A wiring layer and a tiny formula set let designs make new behaviour, all as data with no code downloaded.

Who makes content. AI helpers make about 95 % of it, through a command-line Studio with a full rulebook, precise error messages, preview pictures and videos, test matches against bots, templates and a playbook. A Mac Studio app gives people the same tools visually. Freehand drawing and posing come in a later Studio update.

How it reaches players.

1. Every item passes automatic checks: every arena, every gore level, every phone tier, frame time within budget, two runs exactly equal, and no bug-looking frames.
2. A person approves it.
3. It goes to our test phones, then 10 % of players for a day, then everyone.
4. Phones download new content at the splash screen with a progress bar. If there's no internet, the game carries on with what it has.
5. Online rooms check that everyone has the same content and download anything missing first.
6. Any item can be pulled in one tap. Players keep what they bought: it rolls back to its last good version, or hides until fixed.

What stays the same. Every existing map, film, skin and taunt stays exactly as it is. A proof set (3 maps, 6 films, 6 cosmetics, 4 taunts) is rebuilt in the engine only to prove it matches the originals with zero difference. Players keep the originals.

Safety rules built in. No downloaded code, only data (the app-store rules). The formula set is tiny, and one switch can turn it off. Content can never be gorier than the player's level or the app's rating, never give an advantage, and never run slower than the frame budget. Two phones in a room can never silently disagree.

Build order (the user). One engine at a time, each finished before the next: first the map engine, then the animation (kill film) engine, then skins, then taunts / emotes, then the shared shop / pass catalogue and launch polish.

Cost and time. About 174-212 agent lane-days. The honest calendar depends on how many engine lanes run at once (see §10): the map engine is done in about 9-11 weeks on two lanes, and the whole program is launch-ready in about 7-8 months on one lane, 4½-5½ months on two, or 3¾-4½ months on three. Launch waits for all of it: the engines, the Studio and the proof set.

Decided (6 Nov).

1. Intent

We want more content, faster. Skins, maps, kill films, taunts and emotes, along with everything attached to them (a skin's film, its ammo, its sparks), should reach players from our server with no app update [user].

To do that the game gets one engine. It is a fixed set of building blocks that ships inside the app. Every new item is a document that says which blocks to use and how to set them. Packs of these documents, plus any sound files they need, are pushed from our server. The same game, built for the Mac with its editor turned on, is the Studio. That is where we (our team and Claude agents) build content, test it in real matches and publish it [user]. Agents use the same Studio from the command line on the VM, with no screen [user].

What exists today stays exactly as it is: the ~180 kill tracks, the ~155 film scripts, the 32 code-built arenas, the skins and the taunts [user]. A small proof set is rebuilt in the engine only to prove that it can match the originals exactly. Players keep the originals [user]. The shop, pass, rooms and customize screens treat built-in items and engine items the same way [user]. Moving the old content onto the engine can happen later, item by item, behind a switch that can be rolled back [user]. Launch waits for the engine, the Studio and the proof set [user].

2. Goals, non-goals, anti-goals

Goals

• Ship new skins, maps, kill films, taunts and emotes, and everything attached to them, with no app update.
• Make the engine very flexible. Blocks combine freely, every block has wide settings, anything can attach to anything that has an attach point, and any item can have variants (gore level, device tier, mirror, skin family).
• Use one engine and one tool for every kind of content: the same document model, timeline, gate and publish path for maps, films, skins and taunts.
• Make whole classes of online bugs impossible by design rather than catching them one by one. The Half-float hashAt bug (§3.5) must be impossible to write.
• Bake performance, gore levels and the age rating into the blocks, and check them at publish time. Pushed content can never be slower, gorier or rated higher than the app allows.
• Let an agent take an item from idea to the test channel with no human at a screen. Agents do ~95 % of the authoring, so the agent interface comes first (§6) [user, D3]. A person approves the final publish to players, and the server enforces it [user, D2].

Non-goals

• No player-made content. Creators are us only [user].
• Players keep the existing content. Rebuilding the proof set does not replace it [user].
• No migration of old content before launch. Migration comes later, behind a switch [user].
• No new gameplay rules or weapons through packs. Packs are looks, worlds, films and performances. A new weapon (its damage and handling) still ships in an app update [call].
• No change to the 144 protocol until the engine lands (§5.8).

Anti-goals (things the design must never allow)

• Downloaded executable code of any kind: no scripts, no general expression or scripting language (only the tiny bounded formula set of §5.5a, D12), no plugins, no code inside AssetBundles (Apple 2.5.2 / DPLA 3.3.2, Google Play's Device and Network Abuse policy) [user, hard].
• Two phones in one room that disagree about the content without knowing it.
• A float that comes from content data going onto the wire.
• An item that gives a gameplay advantage. The no-advantage rule of the 3 Nov design (§7 there) applies to every pack.
• A pushed item that is over the age rating, or that shows more gore than the player's chosen level.
• A pushed item that can freeze, stutter or crash a phone. The gate refuses it before it ships, and if one gets out anyway the phone's own budget meter drops it.

3. What exists today (the study)

3.1 Kill films: what is data and what is code

A page kill has two halves:

1. The track (data). Resources/KillTrack/<weapon>_<id>.bytes holds every gore level in one file (Scripts/Core/PageTrack.cs:6-9, format Scripts/Core/PageTrackV2.cs:8-14). It is baked from the HTML kill page by tools/killport/ (bake recorder → pk_pack.py text → pk_pack2.py binary). It runs at 60 Hz (PageTrack.cs:11). It carries the two bodies' 13 joints per frame, the camera (x, y, width, rotation, shear), the speed curve, the weapon rows, the alive / hide / head-gone / ragdoll flags, the events (rounds, flashes, cuts K, blood, soul, cues S, fx T), the multicam views, split screens, panels, whip pans, pips, grades, real grades, key lights, warm spots, grain, contact shadows, material looks (gold / frost / char / tint), blood styles, death cracks, text, trails, piece paths, draw order, and the page's full sound (voices A, beds B, ducks N, library L) (PageTrack.cs:12-120). The v2 file is already integer-quantised: every number is q = value × 10^4 and positions sit on a 0.01 page-unit grid (PageTrackV2.cs:11-14). A decoded level costs ~0.2-0.6 MB, and a match's film pool is decoded on a worker thread (PageTrack.cs:201-232).
2. The film script (code). Each film registers a PageKill.Def from its own file through the auto-registration row (Scripts/Core/PageKills/PageKillRegistry.cs:4-12). The Def has plain fields: key, name, weapon, rarity, arena, wire id, slot, skin family, gap, fx scale, ink-in / out, held-hide windows, voice edits, beds, single camera, stay mode and so on (Scripts/Core/PageKill.cs:44-153). It also has C# hooks: cue, step, draw, drawUnder, drawInset, bodyBack, poseFix, fx, begin / end, drawAfter, drawAfterUnder, room, piecePlace, dryCut, supports, trackOf (PageKill.cs:60-176).

How much of each film is code? I tallied the 155 files in Scripts/Core/PageKills/:

The custom drawing is all vector shapes from the game's one shape batch: Line 535 calls, Circle 249, RawQuad 135, Ellipse 121, Box 46, Glow 39, SoftEllipse 35, then BoxAxis, Arc, Tri, Ring, Star. Colours go through PageKill.PageColor* (~350 calls), and cuts go through FinisherCut.*.

Finding 1. A film's motion is already data. What makes 146 of the 155 scripts code is a small, repeating set of jobs: draw shapes tied to joints and time, keep a few timers, react to a cue, patch the track per gore level, put a real weapon in a hand, leave a mark behind. Each of those jobs can be a block.

Where the films run: FinisherStart → PageKillRotation.Try → FinisherPool.PagePick (PageKill.cs:25-26). The older KillCine timeline library (Scripts/Core/KillCine.cs:6-22: actors, camera language, HUD layers, spot solver) still exists beside it. Gore has six internal levels, and players pick LOW 0, MEDIUM 2 or EXTREME 5 (Scripts/Core/KillSysGore.cs:5-12). The track holds one block per level, and a missing level falls back to g5 (PageTrack.cs:172). Film quality tiers are LOW / MED / HIGH, with a film governor that steps down under load (Scripts/Core/KillCineQuality.cs:48-58). Sound plays the page's voices on the film clock through the page library, the gameplay gun clips and the beds / ducks (Scripts/Core/PageKillSound.cs:6-13).

3.2 Kill films online

The host picks the film and sends one FilmStart at film time 0. Every phone plays the same film locally as "a pure function of the track + time", with a seeded Rng. Gore is local, and the end-state hash covers only gore-independent state (Scripts/Core/PageKillNet.cs:7-20). Films are named on the wire by a u16 wire id from an append-only table (Scripts/Core/PageKillRotation.cs:775-800). The catalogue of key @ wire is hashed into NetProto.ContentHash (Scripts/Net/NetProto.cs:147-160), together with the weapons, moves, arenas and items. A mismatch refuses the join with "host and you run different game builds. Update both" (Scripts/Net/NetHost.cs:413). Protocol is 144 (NetProto.cs:9).

3.3 Maps

• Geometry is already data-shaped. ArenaDef holds plats, movers, props, ice, start weapons, spawns, bounds / camera / kill / focus areas, ladders, pads, low-g zones, decor, hatches and racks. It is built by a small DSL (S, O, Floor, Ledge, Stairs, Ramp, Ladder, Pad, Lift, Cart, LowGrav, Hatch, Spot, Deco, Bounds) (Scripts/Level/Arenas.cs:8-170). Hazards on the older arenas are flags with code behind them: lavaTop, wind, rain, laser, pendulumPivot, train (Arenas.cs:52-57). Arenas travel as indices, and ContentHash covers the list (Arenas.cs:209).
• Moving pieces, events and art are code. A map with a MapScript builds its own pieces (MapPlat: kinematic boxes, one-way or solid, turned, shown / hidden), owns its events and draws itself (Scripts/Level/MapEvents.cs:6-20, :132-187). Events are telegraphed (phase 0 = the warning) and host-authoritative. The host writes each running event's (slot, run, phase, phase time, payload) into the level snapshot, and each event writes its own payload with hand-written Write / Read (e.g. Scripts/Level/MapWreck.cs:341-352, :397-398). The page-90 / 93 maps share a kit: a fixed timeline of cues × the MAP EVENTS pace, props reserved at build time and parked until released, and the small-arena frame (Scripts/Level/MapNewKit.cs:7-17). WRECKING YARD (MapWreck.cs:6-25) is typical. Its geometry is 15 lines of DSL. Its balls, bricks, plank, smash and pallet are ~330 lines of script, event and drawing code.
• Map art is code per map (Scripts/Render/MapLook*.cs, ~45 files), drawn with the same shape batch.
• Map looks are already data with a live overlay. MapLookConf (Scripts/Render/MapLookConf.cs:9-20) has a shipped default JSON, then ops.maplook from the live config, then an event overlay. This is a working pattern the engine copies.
• Bot navigation is computed from geometry. NavGraph builds walkable spans and links (walk, jump, fall, drop, ladder, pad, lift) by simulating the fighter's own movement (Scripts/Fighter/Nav.cs:6-11). A data map gets bots for free, as long as its moving pieces declare how bots should treat them.
• The map export (Scripts/Core/MapExportLab.cs:12-24) writes every playable arena to 58k_maps.json using the element vocabulary (~/StickBrawl-v3/v4/feedback/_tools/58k_ELEMENTS.md: FLOOR, WALL, CEILING, PLATFORM, DROP, GAP, STAIRS / SLOPE, PILLAR, OPENING, HANGING_HEAVY, EXPLOSIVE, BREAKABLE_*, SHARP, HOT, ELECTRIC, LIQUID, MOVING, BOUNCY, CLIMBABLE, ...). It is lossy. It writes page units rounded to 2 decimals (MapExportLab.cs:29), and it holds tags rather than behaviour. It is the right vocabulary for the engine's map elements, but a reverse loader of that JSON cannot reproduce a map exactly. The engine's map document must hold the exact geometry, and can export the 58k JSON as a by-product.

3.4 Skins, cosmetics, taunts

• Cosmetics are recipes. Each item is a CosmeticDef with a slot (Hat, Face, Body, Aura, Trail, WeaponSkin, KillFx, Emote, WinDance, Colour, Outfit, Hair, Back, Plate, Pose), a rarity, a source, a 1-based wire index per slot (append-only), an art recipe enum (HatArt.Crown, OutfitArt.Hoodie, ...) and two recipe colours (Scripts/Render/CosmeticsCatalog.cs:13-58). The drawing for each recipe is C# (Render/Cosmetics*.cs).
• Premium weapon skins attach things. A premium skin carries its round-end film, themed ammo, a death burst, hit sparks and a feed icon (Scripts/Render/SkinContents.cs:5-14). Today GOLD and ICE are the premium families.
• The loadout on the wire is bytes: one u8 per slot, 4 emote ids and a bitmap of skinned weapons (Scripts/Render/CosmeticsLoadout.cs:167-185), capped at WiFiProfile.MaxLoadout = 96 bytes (Scripts/Net/WiFiProfile.cs:23).
• Taunts are keyframe tracks built by a DSL. Each key is a time, an ease (TE), torso / head / drop offsets and hand targets (Scripts/Render/TauntDefs.cs:31-60, TauntRig.cs:15-24). Faces, comic words, props and a voice clip go with them. Taunts are emote ids 22-33, a u8 on the wire, host-decided, with Ev.Taunt telling every client which one (Scripts/Render/Taunts.cs:7-17, :78). Gloats turn a taunt near a KO'd body into its own variant (CHAI BREAK sits on the body, LOSER leaves an L that stays). Emotes 0-21 are hand-keyed poses (Scripts/Render/CosmeticsEmotes.cs:5-10).

Finding 2. All of the game's art is SDF vector shapes from one shader and one dynamic mesh per layer (Scripts/Render/ShapeBatch.cs:9-13: capsule, rounded box, arc, triangle, glow, star, ring, soft, ellipse). The only non-code art is a handful of textures (Resources/Art 744 KB, ItemArt 1.8 MB) and the sound (Resources/Audio 98 MB, 172 kill-library files). So most new art can be pure data (shape lists), with no AssetBundle and no shader at all. Only new sound files, and rare raster art, need bundles.

3.5 Live config, catalogue, server

• The live config is one versioned JSON document. It is cached and checked whole, applied only when its ver is higher, and read through typed sections with built-in defaults (Scripts/Live/LiveConfig.cs:12-25). Film settings are already one of those sections (Scripts/Live/LiveFilms.cs).
• sbapi publishes config versions from the dashboard or CLI. A rollback re-publishes an old version's content as a new, higher version (server/sbapi/config/publish.go:212-214).
• The catalogue: the game exports every item it knows (Scripts/Live/Season/CatalogExport.cs:11-17, items with sinceVersion from CatalogMeta). sbapi keeps one catalogue per app version code (deploy/catalogs/catalog-<versionCode>.json) and auto-picks season passes from it (server/sbapi/seasons/catalog.go:1-8).
• The Half-float lesson (6 Nov). FilmStart sends hashAt as a half float (PageKillNet.cs:45, :58). The host sampled the end hash at the unrounded time, the clients at the rounded one. On 48 of 195 tracks they picked different frames, and the end hashes "differed" (fix 996026f80: the host now samples at the half value too). The deeper cause is that a float derived from content crossed the wire through a lossy type. §5.7 makes that impossible.

3.6 Platform facts

• Unity 6000.3.26f1 (StickBrawl/ProjectSettings/ProjectVersion.txt), IL2CPP with managed stripping (hence the registry rows instead of reflection, PageKillRegistry.cs:9-11).
• The Addressables package is not installed. Content loads through Resources. The built-in AssetBundle and UnityWebRequestAssetBundle modules are present (Packages/manifest.json:17,36).
• Store builds compile the labs out (SB_STORE, Editor/ProjectSetup.cs:562). The lab system runs a player build headless with -batchmode -scenario <name> (cap.sh). The Studio and the agents' CLI are built on that.

4. The idea in plain words

Think of it as LEGO:

• The bricks (blocks) ship inside the app. Examples: "a floor", "a swinging ball", "a hat drawn from these shapes", "a camera cut", "a slow-motion ramp", "a sound at this moment", "the victim's arm comes off here (EXTREME only)". Each brick has settings with safe limits, a known cost and rules for the gore levels. We can only add new bricks with an app update.
• A design (document) says which bricks to use, how to set them and when things happen. Skins, maps, films and taunts all use the same kind of document.
• A box (pack) holds a few documents plus any new sound files. A pack is sealed: its name is its fingerprint, so two phones with the same pack name have exactly the same contents.
• The Studio is our own game on the Mac with an editor switched on. You open a design, see it in a real match against a bot on any arena and at any gore level, change settings, and press GATE then PUBLISH. Agents do the same on the VM by typing commands.
• The gate is an automatic inspector. It plays the item on every arena and gore level and on every device tier, measures the frame time, checks that two runs agree exactly, and looks for bug-looking frames. Nothing reaches players without passing it.
• The server keeps the boxes. It sends them to the internal test channel first, then to a slice of players, then to everyone. It can pull any box back in one tap.
• The shop, pass, rooms and customize screens see one catalogue. A pushed hat and a built-in hat are just two hats.
• New boxes download when the game opens, with a progress bar on the splash screen, before the menu. If there's no internet, the game carries on with what it has (DECIDED, D4 + D5).
• Online rooms compare the list of boxes everyone has. If someone is missing one, they download it (with a progress bar) before they join (DECIDED, D4).

5. Architecture

 STUDIO (Mac, internal build)            HEADLESS CLI (VM / M2 / Mac)
   edit docs · preview in real match       studio.sh validate|compile|preview|gate|pack|publish
        \                                     /
         └──── content repo (git: JSON docs + source sounds) ────┘
                              │ compile (quantise, resolve refs, bake bundles per platform)
                              ▼
                     PACK  (content .sbp, sha256-named · bundles per platform · envelope .sbe: report + signature)
                              │ GATE (schema, budgets, determinism, perf per tier, arenas,
                              │       gore + rating, look checks, exact-match for the proof set)
                              ▼
   sbapi content registry ── content list (channels, rollout %) + kill list (only grows); human approval for live
                              │
          content.stickbash.com (VM origin, Cloudflare in front, immutable URLs)
                              ▼
 PHONE: fetch → verify hash + signature → store → ENGINE RUNTIME (app-shipped blocks)
        → shared catalogue (shop / pass / rooms / customize) → matches (pack-set hash in the join)

5.1 The runtime

The runtime is one C# module inside the app (Scripts/Engine/):

• Pack store. Packs on disk (Application.persistentDataPath/content/), verified on load. The sha256 of the pack's content is its name (§5.8). Its envelope carries an Ed25519 signature by the gate's publish key, whose public half is built into the app. It keeps an LRU of unused packs under the size caps: ≤ 5 MB per pack, ≤ 150 MB in total (DECIDED, D6). Packs that hold an owned item's current revision or its previous live revision are pinned and never evicted (§5.13).
• Loader. It reads a pack's compiled documents (a compact binary, like the v2 track: varints, string table, deflate). It resolves references and asks the AssetBundle loader for any sound. It loads off the main thread, the way PageTrack.DecodeV2 and the film pool already do (PageTrack.cs:201-232).
• Validator. It runs on the phone again, even though the gate ran. It checks the engine version, that every block id is known to this app, that every setting is in range and every reference resolves, and that budgets are met. A document that fails is dropped whole, with a telemetry line, and the item hides. It never half-plays.
• Interpreters, one per content kind, all driven by the same timeline core:
  • Film: the engine's film blocks run on today's page-film engine. A MotionTake block is a v2 track, played by the same Finisher / PageTrack path. The blocks replace what the per-film hooks do (§5.2 B). So the motion, camera, sound and gore that already pass the port gate are reused, not rewritten.
  • Map: it builds an ArenaDef from the geometry blocks (the same class the code maps fill), then a generic EngineMapScript : MapScript that runs the pieces, hazards, timeline and events from blocks, with a generic payload writer (§5.7).
  • Cosmetic: a generic recipe drawer. A rig of shapes is attached to body joints or weapon parts, and the premium attachments point at engine or built-in content.
  • Performance (taunt / emote / win dance / gloat): a TauntTrack built from keyframe data, plus face, words, props and clip.
• Budget meter. Every block reports its cost each frame (shapes, particles, voices, colliders, insets). If a document is over its tier's budget at runtime (which the gate should have stopped), the meter drops its optional look parts in a fixed order. This is the same idea as FilmQ's governor, now per block. It never drops or changes a sim part, since that would split host and clients. A sim overrun is only reported in telemetry, and the gate is what prevents it.
• Ownership and saves use the engine item's string id (eng.hat.lantern), never a wire index, so a save survives any pack revision. The u8 slot indexes stay for built-ins only.

5.2 The block library

A block is an app-shipped C# class with a stable id (film.prop, map.pendulum, ...), a typed parameter schema (every number has a unit, a grid and a range), a cost formula, a tier rule (what it drops at LOW / MED), a gore rule (which levels it may appear at, and what it becomes below that level), a determinism class (sim: changes the match state, host-authoritative, hashed; look: drawing / sound only, may differ per phone) and its attach points. The library has a version number (ENGINE_API). It only ever grows: block ids and parameter ids are append-only, a removed block keeps its id, and a parameter's meaning never changes (§5.8).

The families below cover everything the study found in today's content. Every row names the existing code it wraps, so the first version is mostly a wrapper around tested code, not new behaviour.

A. Common blocks (every kind of content)

B. Film blocks

C. Map blocks

Bot navigation is not a block. The runtime builds NavGraph from the solids and traverse blocks, exactly as for code maps, and pieces add their nav hint.

D. Cosmetic blocks

E. Performance blocks (taunts, emotes, win dances, gloats)

The tables above wrap today's content. They are the floor, not the launch library. A block that isn't in the app can't be pushed later without an app update, so the launch library also carries a broad set of blocks the game doesn't have yet (§7, "NEW BLOCKS BEYOND TODAY'S GAME") [user, 6 Nov].

How flexibility grows. Blocks compose: any rig on any anchor, any driver on any number, any variant on any setting, and any logic-graph wiring of sources to sinks (§5.5). New behaviour comes from new combinations, with no new code. When a design needs something no block can say, we add a block or a parameter in the next app update (§5.8). Packs that need it are offered only to apps that have it. That is a normal app update, which the store rules allow, and it keeps every pack declarative.

5.3 The content document model

Every item of every kind is one document with the same envelope. The authoring form is JSON in the content repo (diff-friendly, agents can write it). The compiled form inside a pack is binary.

{
  "doc": "film",                          // film | map | cosmetic | performance | (shared) rig | palette | soundset
  "id": "eng.smg.night-shift",            // stable, namespaced; never reused
  "rev": 3,                               // author's revision (the pack hash is the real identity)
  "engine": 1,                            // the minimum ENGINE_API this doc needs
  "name": "NIGHT SHIFT", "rarity": "EPIC",
  "rating": { "gore": [0, 2, 5], "flags": [] },   // gore levels it authors; content flags (§5.10)
  "uses": ["eng.pack.core-props/rig.ink-sword", "builtin:weapon/smg"],   // its references, resolved at compile time
  "variants": { "gore": {...}, "tier": {...}, "mirror": true },
  "blocks": [ { "b": "film.take", "id": "take", "p": { "track": "take:night-shift" } }   // a pack-local ref, never a file path,
              { "b": "film.prop", "id": "slab", "p": {...}, "states": {...} } ],
  "timeline": [ { "at": 54, "do": "slab.show" }, { "on": "cue:shot3", "do": "slab.state:holed" } ],
  "studio": { "notes": "...", "thumb": {...} }     // stripped from the compiled pack
}

Rules:

• Ids are namespaced and stable. Engine items are eng.<kind-or-weapon>.<name>. Built-ins keep their ids (revolver.six-shooter, hat.crown, wreck), and a document refers to them as builtin:<registry>/<id>. No engine id can equal a built-in id, and the catalogue refuses a clash.
• A document is self-describing and fully resolved at compile time. The compiler turns every time into ticks, every length into millimetres, every angle into 1/65536 turns and every colour into bytes. It inlines palette refs, checks every reference, and records the doc's dependency list (other packs by hash, built-ins by id).
• Shared documents (rig, palette, soundset) let a whole family reuse one asset: an ink-sword rig, the Gold theme palette, a music-kit soundset. They live in library packs.
• Variants are patches on settings, not copies. Per gore level (what changes at LOW / MEDIUM / EXTREME), per tier (what LOW drops), mirror (left / right). The gate plays every variant.

5.4 Attachments and composition

• Attach points are a fixed, app-shipped list: the 13 body joints (PageTrack.cs:135), the head disc, the weapon's parts (WeaponDef.parts), the muzzle, a film piece (FinisherCut part), a world point, a map element (by kind and id), the camera / screen. Every rig, prop, mark, fx and text names one.
• Composition by reference. A premium skin's cos.premium.film points at an engine film document or a built-in film key. A film's film.prop uses a rig from a library pack. A map's map.art uses a palette document. References resolve at compile time to (pack hash, local index) or builtin:<id>. A pack may reference only built-ins, itself, and the packs listed in its manifest's deps (each pinned by hash). No cycles, no "latest": a reference never floats to a newer revision.
• What a skin can carry (the user's example, "for skin we can attach animation"): the look (art + palette), a round-end film (engine or built-in), themed ammo, hit sparks, a death burst, a feed icon, and its film rule. Later blocks can add more (a kill sound set, an equip animation) without changing any pack already out.
• Overrides are explicit. A document may override a built-in only through the migration switch (§5.14), never by reusing its id.

5.5 Timelines, triggers and the logic layer

One timeline core and one logic layer serve every kind of content. The user asked (6 Nov) for "additional things too which is not in game now (like for example additional elements or logics or things for maps etc)" [user]. Fixed blocks alone can't express new behaviour, so it has to come from combining them. The logic layer is how blocks combine, and it stays data.

Time. Time is an integer tick. Films use film ticks (60 Hz frames of the take, the same grid as PageTrack). Maps use fight ticks (the fixed step). Performances use performance ticks. No content time is ever a float.

The simple form: a timeline + rule list. Most films, skins and taunts need only this.

• Triggers (when): at <tick>, window <t0> <t1>, on cue:<name> (a track S cue or an event tag), on game:<event> from a fixed list (the gameplay-event sources of the logic graph below), when <condition>, gore <set>, tier <set>. A trigger may also require a state (piece.slab == holed).
• Actions (what): show / hide, set a state, start a driver, emit fx, play a sound, place a mark, cut, set / add a counter, release a reserved prop, start a map event phase, camera / clock / grade moves. Each action belongs to a block and is app code.

The full form: the logic graph. Maps and complex films use this. It works like wiring switches, timers and lamps on a board, and the Studio shows it as a node graph:

• Nodes come from a fixed, app-shipped set in three groups:
  • Sources: tick / timer, zone (enter, leave, count), plate, proximity, switch, score, alive count, round phase, a seeded random, a counter, a piece or hazard state, a film cue, a gameplay event.
  • Logic: AND, OR, NOT, XOR, compare-with-a-constant, edge (rising / falling), latch, toggle, delay n ticks, pulse n ticks, sequence, select (seeded random / round-robin), counter (add, sub, clamp, wrap), timer (one-shot / repeat), once, cooldown.
  • Sinks: the actions of blocks (§7).
• Values on the wires are booleans and small integers (i16). There are no floats, no strings and no lists.
• Evaluation: one pass per tick, in an order the compiler fixes (topological). The same one-pass rule holds for the simple form. An action takes effect for triggers on the next tick, never in the same one, so a counter that re-fires its own trigger advances at most once per tick. Counters are i16 and saturate (no wrap unless a wrap node says so). A wire may loop back only through a state node (delay, latch, counter, timer, toggle), and that node reads the previous tick's value. So there are no instant feedback loops, and a tick always finishes.
• Bounds per document (checked by the compiler and again on the phone): ≤ 256 nodes, ≤ 1024 wires, ≤ 32 counters / timers, ≤ 64 sinks firing per tick, and a fixed logic-state size (≤ 64 bytes, the size of its slot in the level snapshot). Every node costs O(1) per tick, so the worst-case cost is known before the item ships (§7 budgets).
• Determinism: sim logic runs on the host only. Its packed state rides the level snapshot through the generic writer (§5.7 rule 4). Clients pose everything from that state, and look-only logic (a skin's glow on hit) runs on each phone on its own. Randomness comes from seeded streams only (§5.7 rule 5, rng.stream §7.6).
• Why this is not a scripting language: it has no instructions, no named variables, no unbounded loops, no functions and no way to reach any app API except the fixed sinks. The state space is a fixed-size finite state machine, laid out by the compiler. This is how the engine stays data, not a scripting language, which the store rules require [user, hard]. The one exception is the tiny formula set (§5.5a, DECIDED D12): a bounded arithmetic value that may stand in for a constant in a parameter slot. It adds no control flow.

State machines for pieces and props. These are a finite set of named states with timed or triggered transitions, which the logic graph can drive. The Wrecking Yard plank (up → smashed → rebuilt) and DRIP's slab (cast → whole → holed) work this way.

5.5a The tiny formula set (DECIDED, D12, 6 Nov)

The user chose (B), overriding the recommendation, because it makes AI-made content more flexible [user]. A formula is a bounded arithmetic value that may replace a constant in a parameter slot that allows it. Example: an aura's glow = clamp(lerp(0.2, 1.0, speed / 6m/s), 0, 1).

• Where a formula may go. Every parameter in a block's schema declares expr: none | look | sim (§6.1).

  • none: a constant only. This covers all ids, refs, enums, counts, sizes of fixed tables, tick positions of timeline keys, gore-ladder settings and every budget cap.
  • look: a formula allowed on a drawing / sound parameter: colour channels, alpha, size, glow, rate, pitch, volume, a driver's amplitude.
  • sim: a formula allowed on a sim parameter of a map block: a mover's speed, a field's strength, a level's rise rate, a hazard's on / off period, a spawner's interval.
  • Film online state and every gore / rating / budget setting are none.

• Operations (fixed): add sub mul div (div by zero = 0), min max clamp abs, lerp(a, b, t) (t clamped 0..1), step(edge, x) (x ≥ edge → 1 else 0). Literals carry units (6m/s, 1.2s), and the compiler checks the units agree.

• Inputs (named, read-only signals, fixed per block family and listed in the schema):

  • time: fight time, film time, time since the item started, time since its last trigger;
  • the wearer / owner's own state (cosmetics, performances): speed, health, airborne, facing;
  • the map's state (maps): alive count, score, round phase, the logic graph's counter and timer values;
  • distance: between two of the document's own anchors (e.g. a mover and its pivot), never to another player;
  • gore level and device tier (read-only; the gore ladder still clamps every gore block).

  No-advantage rule: a cosmetic formula may read only its own wearer's state and time, never anything about another player (no "glow when an enemy is near").

• What a formula can't do: no loops, no recursion, no variables, no function definitions, no strings, no conditionals beyond step / min / max / clamp, no writes. A formula only ever produces one number for its slot.

• Size and parsing. At most 32 nodes per formula. The compiler parses the text to an AST at publish time, validates it (ops, inputs allowed for that slot, units, node count) and stores it as a compact prefix array. The phone validates the AST again on load. A bad formula drops the whole document, like any other invalid value.

• Determinism.

  • sim formulas evaluate in fixed point (Q16.16 in int32, saturating; div rounds toward zero; lerp / step in fixed point), on the host only. Their results feed replicated state (§5.7 rule 3), so phones never compare them and gate runs repeat exactly.
  • look formulas evaluate in float on each phone and never enter a hash.
  • Inputs are read at a fixed point in the tick (after the logic graph), so evaluation order is fixed.

• Budget.

  • Per document: ≤ 64 formulas.
  • Per frame on the LOW reference phone: ≤ 2,048 formula nodes evaluated for look, and ≤ 1,024 per fixed step for sim (≈ 20 µs each).
  • The static cost is in the item's budget sum, and the runtime meter counts real evaluations.

• Server kill switch.

  • The content list carries one flag, formulas: on | off. When it is off, every formula slot uses its declared fallback constant. The schema makes the fallback mandatory ({ "expr": "…", "else": 0.6 }), and the gate renders and plays every item with formulas off too, so the fallback must also look and play right.
  • The flag is read at match start and goes into the room's pack-set hash, so a room never mixes the two modes mid-match.

• App-review risk (note). A downloaded formula is closer to "code" than plain numbers. Apple 2.5.2 forbids downloaded code that changes features, and Google's policy is similar. The mitigations:

  • the set is a fixed, tiny arithmetic language over a fixed list of inputs, filling only a declared number slot; it can't call any API, change control flow, loop or keep state (it is like a spreadsheet cell, not a script);
  • formulas are written by us only, gated and signed;
  • the review notes describe them plainly;
  • the kill switch turns them all off at once if a reviewer or a policy change asks.

  Residual risk: small, but higher than option (A). If a review objects, we ship with formulas: off and every item still works on its fallbacks.

5.6 Gore and the age rating

• Gore lives in the blocks, not in the packs. Only app-shipped blocks can cut, bleed, pop a head or show anatomy, and each one follows the level ladder of KillSysGore (MEDIUM: no limbs off, LOW: no blood; KillSysGore.cs:5-12). A pack can choose less gore than a block allows, never more. No pack can add a new kind of gore. The rating ceiling is the app's.
• Every film authors its three player levels (LOW / MEDIUM / EXTREME), as the takes do today (DECIDED, D11).
• A film's online state is gore-independent. That state is the killer's pose, the victim's death state (root, facing, down / gone), the end tick and the match result. Cuts, pieces, blood and wounds are look (they follow the gore level) and are never in the online hash.
• Same length at every level (new films) [call]. A new engine film must have the same tick length and the same online state at all three levels, and the gate refuses it otherwise. Built-in takes do differ per level today: hashAt is "the shortest gore level's length" (PageKillNet.cs:30, the W11 ladder f630a3197). So film.take has a legacy ladder mode (end at the longest level, hash the killer at the shortest), used by the proof films and any imported legacy take.
• Content flags: each document declares a small, fixed set of content flags (blood colour, dismemberment, fire on bodies, horror realm, rude gesture, text in a pack's string table). The gate checks them against the app's AgeRules ceiling and against a word list for the string table. Words, signs and names are pack strings, so they are checked like the existing NameRules.

5.7 Determinism by construction (the Half-float class made impossible)

These rules make the 6 Nov class of bug impossible to write:

1. Integer grids at authoring time. The compiler quantises every content number once, onto a declared grid: ticks, mm, 1/65536 turns, and 1e-4 units for dimensionless numbers (as v2 tracks already do). The runtime stores these integers and converts to float only at the very end, for drawing and physics input. Any "sample time" (an end-hash tick, a film length, a cue time) is an integer that every phone reads from the same pack bytes.
2. The wire carries no content floats. Engine content travels in new messages written by a typed writer, EngineWriter. It has only ContentRef, Tick (u16 / u32), Seed (u16 / u32), small ints, enums and the snapshot's existing quantised position type (Pos: int16 mm). It has no F32 and no Half method, so a lossy float can't be added by mistake.
   • An engine film is started by EngineFilmStart, not FilmStart. It carries the film ref, the seed, the fighters, their feet and floor as Pos (mm), the room shift in mm, the start, length and hash points as ticks, and the host's start as a snapshot tick.
   • Built-in films keep FilmStart exactly as it is (PageKillNet.cs:43-58, Half and F32 fields included). The engine does not touch legacy content, so that path keeps today's rules and today's fix.
3. Two kinds of online state. The rule for each is different:
   • Replicated state is computed on the host only and sent quantised: map pieces, hazards, the logic graph, spawns, props that collide, event phases. Phones never need to agree on how it was computed, only on the bytes they receive. Each phone poses its own picture from those bytes with a pure function (state ints, tick), the way WRECKING YARD's balls follow the clock (MapWreck.cs:23-25). Float maths inside that pose function (the pendulum's trig in Level.PendAngleAt, Box2D contacts) stays on the phone and is never compared.
   • Recomputed-and-hashed state is what every phone works out for itself and then compares: today only a film's online state (§5.6). It must be integer, or quantised to the wire grid before it is hashed. Anything computed in floats (IK in film.posefix, a film prop's floor bounce) is look and never enters the hash.
   • look blocks (gore, tier extras, fx, sound, grade) may differ per phone and never enter a hash.
4. A generic event payload. A map.event and the logic graph declare their state fields (ints with ranges). The runtime writes and reads them generically into the level snapshot (MapEventSnap), so there is no hand-written Write / Read that can drift between host and client.
5. Seeded randomness only. Random draws come from named streams seeded by a stable hash (FNV-1a over the id bytes, never string.GetHashCode) of the round or film seed, the content id, the instance and the stream id. The gate records each stream's draw count per tick.
   • For the proof maps, a director-compat stream reproduces today's shared map-director Rng and its seed formula exactly (MapEvents.cs:192, :314). PALLET's x (MapWreck.cs:385) and Belt Line's crate x (MapBeltLine.cs:361) draw from it in today's order.
   • New content never uses the compat stream.
6. Golden determinism runs at the gate, in three steps:
   • Every document plays twice in one process; the per-tick state hash must match on every tick, not only at the end.
   • It plays again on the other desktop build (Mac vs Linux headless).
   • Before it can leave the test channel, it plays on the reference phones (one iOS ARM, one Android ARM), because a Mac / Linux pair can't show what ARM maths does.
   • A mismatch in recomputed-and-hashed state fails the gate and names the first tick and block.
7. The end hash uses the same rules. The film end hash samples at the doc's declared end tick, which is an integer from the pack. Its value is the same at every gore level (§5.6), or the legacy ladder rule applies for imported legacy takes.

5.8 Versioning, pack hashes, compatibility

• ENGINE_API is an integer in the app (1 at launch). Each document declares the engine it needs, and an app shows and plays only documents whose engine ≤ its own. Others stay downloaded and silent until the app updates.

  • Block and parameter ids are append-only. A parameter's meaning never changes, and a new behaviour gets a new parameter or a new block.
  • Any change to how a sim block behaves, even a bug fix, bumps ENGINE_SIM, a second integer.
  • The join carries both numbers. Engine maps and engine films are offered in a room only when every member has the same ENGINE_SIM. Built-in content, and the members' cosmetics (which are look only), are not affected.

• A pack is three parts:

  • the content (.sbp): the compiled docs, plus a manifest with the pack id, revision, engine, ENGINE_SIM floor, deps by hash, the docs' ids and kinds, and the hash of each platform bundle;
  • the bundles: one AssetBundle per platform (iOS, Android, Mac, Linux for the VM gate), present when the pack has sounds or raster art;
  • the envelope (.sbe): the gate report, the Unity version and texture formats the bundles were built with, the approval record, and the Ed25519 signature over the content hash and the report.
  • The pack's identity is the sha256 of the content alone. Nothing in the content refers to the envelope, so the hash isn't circular.
  • Files are immutable: a fix is a new revision, which is a new hash.

• The room content set. Packs fall into two groups in a room:

  • What the room can play (engine maps and films the host may pick): only packs that every member has, or can fetch and run (its engine / ENGINE_SIM). The host builds this list at match setup, sorted by hash. Its 64-bit hash goes into the hello / join / relay create next to ContentHash (NetHost.cs:275, OtSession.cs:228-229). The relay server stores and compares it like ContentHash, which is a relay change in Stage 2 (Task M.8).
  • What members wear (their cosmetics and taunts): each member announces the pack hashes of its equipped engine items once, in its profile block. Others fetch those packs in the background, and until a pack is ready (or if their app is too old for it), they draw that slot as the built-in default. Cosmetics are look only, so this never splits the match.
  • A joiner missing a playable pack downloads it with a progress bar, then joins (DECIDED, D4).
  • Wi-Fi rooms with no internet: the playable set shrinks to what every member already has, and cosmetics use the default fallback.
  • Staged rollout (§5.13) only controls what the shop offers. Any approved pack hash can always be downloaded, so a joiner outside the rollout bucket can still fetch what the room plays or what a friend wears.

• Content refs on the wire are ContentRef = (u8 index in the room's table, u16 local index). The room's table is the playable set plus the announced cosmetic packs, built identically on every phone.

• The loadout cap [call]. Today v2 worst case is 127 B against WiFiProfile.MaxLoadout = 96 and relies on dropping skins (CosmeticsLoadout.cs:183-185). At protocol 145:

  • the cap rises to 192 B;
  • each engine slot costs 3 B (ContentRef);
  • when a loadout is still over the cap, items are dropped in this order: PLAIN skins, then engine weapon skins, then other skins, then engine body slots;
  • the header and the built-in slots always go, so nobody is shown undressed.

• Protocol. The engine needs one bump, 144 → 145, when it lands. It covers:

  • the pack-set hash and ENGINE_API / ENGINE_SIM in the join and the relay;
  • EngineFilmStart;
  • a ContentRef in the taunt event;
  • the loadout extension and its new cap;
  • the arena field for an engine map;
  • the generic map / logic snapshot block.

  NfOldRoomProtocol already shows how an old build is kept out of a new room (Scripts/Net/NetFilmLab.cs:20). There are no players yet, so the bump costs nothing if it lands before launch [call].

• PageKillWire stays as it is. It is append-only and covers built-in films only (PageKillRotation.cs:775-800). Engine films never take a wire id: they travel as ContentRef. Built-in ids, emote ids 0-33 and cosmetic slot indices are untouched.

5.9 Asset delivery (sound and the rare raster)

• Vector first. Art is shape data in the documents (Finding 2). Most packs have no bundle and are a few KB to a few hundred KB.
• AssetBundles for new sound and raster art [user]. Only the Unity Editor can build bundles (BuildPipeline), not a player. So studio.sh pack hands that step to a bundle lane: the Unity Editor (6000.3.26f1, the same version as the app) in batch mode, with the iOS, Android, Mac and Linux modules installed. It runs on the Mac or the M2 first and on the VM once its Editor is set up (Stage 2, Task M.9). It builds one bundle per platform: iOS, Android and Mac for players, Linux for the VM gate. The envelope records the Unity version and the texture formats (ASTC for iOS / Android, DXT / BC for desktop). They hold only AudioClip and Texture2D (and Font if ever needed). Bundles may never contain a MonoScript, a shader, a material with a custom shader, or a prefab with components. The gate opens each bundle and refuses any other type. Textures draw with the game's shipped shaders only, so there are no new shader variants to precompile. We use the built-in AssetBundle API with our own manifest rather than adding the Addressables package [call]: the pack manifest already does Addressables' cataloguing, and we avoid its stripping, catalogue and build-time cost.
• Clips use the game's existing import settings (Vorbis, the kill library's sample rate), so a pushed sound behaves like Resources/Audio/Kill.
• Size caps (DECIDED, D6): ≤ 5 MB per pack and ≤ 150 MB in total, with LRU eviction of unused packs; owned items' packs are always kept. The gate refuses a pack over 5 MB on any platform.

5.10 The Studio (Mac app)

The Studio is the internal Mac build of the same game (non-SB_STORE, like the lab builds) started with -studio. It is never in a store build. Its screens:

1. Library: every document in the content repo and every built-in item (read-only, as a reference and a source to copy settings from). Filters by kind, weapon, map and status (draft, gated, live).
2. Editor: the real game view plus a timeline (tracks per block, keys, triggers, a scrubber at tick resolution, gore / tier / mirror toggles) an inspector (every parameter with its range, unit and cost) and a logic-graph view (nodes and wires, with live signal values while the item plays). Undo / redo. Live reload: saving the JSON re-plays at once.
3. Try it: drop the item into a real practice match against a bot on any arena (films: force the K.O. with this film, as the KILL TEST does; maps: play the map with 1-7 bots and any MAP EVENTS pace; cosmetics: wear it, see it in films and previews; performances: taunt on the bot's body).
4. Import: bring a baked track in from the kill-page pipeline (tools/killport), bring sounds in (with loudness and length checks), take shapes from an SVG-like path list, and turn a built-in item into a draft document as a starting point (this is how the proof set starts).
5. Gate: run the gate locally (a fast subset) or on the VM / M2 (the full gate), and see the report: per-tier frame times, the arena strips, the determinism result, gore / rating, look-check frames.
6. Publish: pick the pack, the channel and the rollout, and request approval (a person approves live, D2).

DECIDED (D3, 6 Nov) [user]: the Studio works for all four kinds at launch (option A). Freehand drawing and the posing tool come in a later Studio update, and the data model already allows them (§6.7). The user expects AI agents to build ~95 % of content and people ~5 %, so the headless agent interface is the Studio's primary product, ahead of the visual editor (§6). The visual editor is a view over the same documents and commands.

5.11 The headless CLI (agents)

This is the command surface. §6 describes the full agent-first design around it (schemas, errors, preview, test-play, hot reload, playbook).

tools/studio.sh <command> runs the same Studio player with -batchmode -scenario studio:<command> (as cap.sh does for labs). It works on the VM (Linux headless player, CPU-only steps), on the M2 worker and on the Mac (GPU steps: frames, video, perf). Every command prints one JSON report and exits non-zero on failure:

Agents work in the content repo, which is a git repo of JSON plus source sounds (DECIDED, D15: a new private repo farisbasha/stickbash-content; the layout is in §6.4). They commit by path and run the gate on the VM, and the report is attached to the publish.

5.12 The quality gate is the publish step

publish refuses a pack without a passing gate report that has the same pack hash. The gate is today's PORT GATE (~/StickBrawl-v3/v4/feedback/_tools/PORT_GATE.md) and the in-game kill performance rules, automated and applied to every kind of content:

1. Static: schema, ranges, references, engine version, bundle contents (§5.9), string table words, static budget (sum of block costs per tier ≤ the kind's budget).
2. Determinism: §5.7 rule 6, on every variant.
3. Performance per tier: the reference players at LOW / MED / HIGH (FilmQ.LabForce) and with -perfslow 6, on the Mac / M2 (GPU). The headless Linux VM reports CPU ms only, never p95. Frame p95 ≤ 16.7 ms, max ≤ 33 ms, begin ≤ 16.7 ms, 0 B GC per frame in steady state, no hitch at start or end. Per-block budgets are enforced. A block over its budget fails with its name. Before a pack leaves the test channel it also runs the perf and determinism scenario on the reference phones (an iOS phone and a LOW-tier Android, named in the plan). This is a step in the pipeline for every pack, not a one-off check.
4. Coverage: films on all arenas (home + every arena that fits, plus a clean refusal where it doesn't) at all three gore levels; maps with 2, 4 and 8 fighters, bots only, at every MAP EVENTS pace, HAZARDS on / off, online host + client; cosmetics on every body style, in films and previews; performances on flat, slope and moving floors, and as a gloat.
5. Look checks (PORT_GATE §4, the automatic part): limbs through solids, floating or sinking bodies, blood in mid-air or on sky, particles frozen or left after the film, the camera leaving the subject or clipping, black frames, the HUD back after hand-off. A flagged frame goes to the coordinator's review sheet.
6. Gore + rating: each level's content against the ladder and AgeRules.
7. Exact match (proof set only, §8.1) and the block tests of every block the item uses (§8.6).
8. Human look: the coordinator's side-by-side sheet, then a person's approval for live (D2).

When all of these pass, the gate signs the report and the pack's manifest. The phone checks the signature.

5.13 Server registry, CDN, rollout and rollback

• sbapi content module (new, Go, beside config and seasons):
  • a packs table: hash, id, rev, engine, ENGINE_SIM floor, deps, size per platform, envelope hash, status draft → gated → approved → live → retired, who / when;
  • an item history: item id → its revisions in order (pack hash, status), which is what "the last good version" means;
  • a reverse-dependency index: which packs use a pack;
  • an upload endpoint that stores the content, bundles and envelope.
• Who can do what (enforced by the server, not by trust; DECIDED, D2 [user]). Agent tokens can upload and move packs up to gated, and publish to internal / test. Only a human dashboard account can approve and move a pack to live. The approval is recorded in the envelope. The gate's signing key lives in the VM's secret store, separate from the agents' tokens. A leaked agent token can't reach live players, and a leaked signing key still can't change what is listed live (that needs a human account).
• Delivery (DECIDED, D14): content.stickbash.com is Caddy serving /p/<sha256>.sbp, /e/<sha256>.sbe and /b/<sha256>.<platform>.bundle from the VM, with Cloudflare in front (the same Cloudflare + Caddy stack as deploy/stack/). URLs are content-addressed, so they are cached forever and need no purge. A second origin can be added later without changing the phone.
  • How things are fronted today (checked read-only on 6 Nov; nothing changed):
    • stickbash.com, www and api.stickbash.com are on Cloudflare DNS and proxied (server: cloudflare, cf-cache-status: DYNAMIC). The API's origin is the VM's Caddy with a Cloudflare Origin CA certificate, zone SSL mode Full (strict) (deploy/stack/host-site.caddy.tmpl:1-11).
    • relay.stickbash.com is DNS-only to the VM (172.198.61.163), because UDP can't be proxied.
    • bashatest.howincloud.com is direct to the VM's Caddy (not proxied).
    • content.stickbash.com does not exist yet.
  • To set up before launch (Stage 1, Task C.10; a person with Cloudflare access does the dashboard steps):
    1. A DNS record content.stickbash.com → the VM, proxied (orange cloud).
    2. A Caddy site block from a new template beside host-site.caddy.tmpl, with the same Origin CA certificate. It serves only /p/, /e/ and /b/ from a read-only content directory with Cache-Control: public, max-age=31536000, immutable; everything else is a 404.
    3. A Cloudflare cache rule for that host: cache everything, edge TTL ≥ 1 month, respect origin headers. Without it Cloudflare would not cache .sbp / .bundle files by extension.
    4. An upload path from sbapi's content module into the content directory, written once per hash and never overwritten.
    5. A check that a cached file is served from the edge (cf-cache-status: HIT).
  • Files stay ≤ 5 MB (D6), which is within normal CDN use of the Cloudflare plan.
• What is live: its own versioned document. Content gets its own document, the content list: per channel, the enabled pack hashes, the rollout percentage (a stable bucket of the player id), platform and minimum app version. It uses the same publish / version / rollback machinery as the live config (publish.go:212-214: rollback re-publishes an old version as a new, higher one), but it is a separate document. A content rollback never reverts prices or map looks, and a config rollback never brings content back.
• The kill list only grows. It is a separate short list of pulled pack hashes, served with the content list and never rolled back. Un-pulling a pack is an explicit new entry ("restore "), done by a human. A pulled pack stops being offered and stops playing at the next fetch. Pulling cascades: every pack that depends on it (the reverse index) is pulled with it, and the dashboard shows that list before the human confirms.
• Owned items when a pack is pulled. The phone keeps each owned item's current pack and its previous live revision pinned (§5.1).
  • If the item has an earlier live revision, it falls back to that one.
  • If it has none, the item hides but stays owned, and comes back when a fixed revision goes live.
  • A premium skin whose attached film is pulled keeps its look and plays the built-in film for that weapon until the fix.
  • DECIDED (D13): they keep it, as above.
• The phone: download at app open, blocking with progress (DECIDED, D4 + D5, 6 Nov) [user + coordinator's call]. The user: "initially most of the time we block app until download complete, like we show downloading content progress in splash or something, u decide".
  • At app open the splash fetches the content list and downloads every required or new pack for this app (its channel, platform and ENGINE_API), on any network, before the menu. It shows a progress bar: "Downloading new content… 3.2 / 7 MB". The per-pack and total size caps apply (D6).
  • Every pack is verified (hash + signature) and stored, and only then registered in the catalogue. A pack that is half downloaded or fails to verify never shows.
  • Offline or failing: after a short retry (about 3 tries over ~10 s), the app continues with its cached packs and shows a small "new content waiting" note, retrying in the background. It never blocks forever.
  • Mid-session: a pack published while the app is open is fetched in the background when the next content list arrives.
  • Rooms still verify at join (§5.8). If a playable pack is missing (for example one published mid-session), the joiner downloads it with a progress bar and then joins. The room can't start until every member has it.
  • Downloads and failures go to the existing telemetry path.
• Channels: internal (our devices, the Studio), test (opted-in testers and the VM bots), live. The rollout order is DECIDED (D9): our test phones → 10 % of players for a day → everyone, with a one-tap pull-back at every step.

5.14 The shared catalogue

• One interface, ContentCatalog, lists every item: built-in items (from CosmeticsCatalog, PageKill, Arenas, Taunts) and engine items (from registered packs), each as one CatalogItem with id, kind, slot, rarity, source, price, theme tags, sinceVersion / engine, owned state, preview hook and the content to play. The shop, pass, rooms, customize, kill shop, album and preview screens read only this interface. Built-ins are adapted, not changed.
• Ownership is by id. An engine item's id never changes across revisions, so a fix never takes an item away.
• Server side: CatalogExport adds pack items (with engine instead of only sinceVersion). sbapi's season auto-pick treats an engine item as pickable for an app version only when that version's ENGINE_API ≥ the item's engine, and only when its pack is live on that platform. Prices and pass rewards stay in the live config, as today.
• The migration switch (later, [user]): a migrate table in the content list maps a built-in key to an engine document ("revolver.six-shooter": "eng.revolver.six-shooter"). The catalogue then plays the engine version under the built-in id. Rollback = remove the row (a content-list rollback). Before launch this switch exists but is empty, and only internal builds can set it for the proof set.

5.15 Store compliance (why this is allowed)

• Everything downloaded is data (documents of block ids and numbers, strings, audio, images) read by code that shipped in the reviewed app. There is no interpreter for a language. The logic graph (§5.5) is a fixed-size network of app-shipped parts: no instructions, no named variables, no loops except through one-tick state nodes, no functions, and a hard cap on nodes and state. The tiny formula set (§5.5a) only computes one number for a declared slot from fixed inputs with fixed arithmetic operations (≤ 32 nodes, no loops, variables, strings or functions). It has a server kill switch that falls back to constants.
• Bundles hold no scripts or shaders, and the gate and the phone both check this.
• New features (new blocks) arrive only in app updates that go through review.
• Pushed content stays within the app's age rating and the no-advantage rule.
• The App Store review notes and the Play listing will say: "The app downloads new cosmetic items, arenas and animations as data files; no executable code is downloaded" [call].

6. AGENT-FIRST AUTHORING

DECIDED (D3, 6 Nov) [user]: "most of the time the ai agent will build this, I mean 95% of the time, 5% of time we may manually create maps, so prioritize things make ai agent easier and flexible and customizable".

In plain words. The main user of the Studio is an AI helper typing commands, not a person dragging things. So the Studio comes with:

• a complete written rulebook for every kind of item;
• error messages that say exactly what is wrong and how to fix it;
• pictures and videos the helper can look at to check its own work;
• test matches against bots that report numbers;
• ready-made templates and worked examples;
• a step-by-step playbook for making a map, a film, a skin or a taunt.

A change should show up as a picture in under 30 seconds. The visual editor, and later the drawing and posing tools, sit on top of the same files and commands, so anything a helper makes a person can open, and the other way round.

6.1 The schema: one versioned, documented contract per kind

• A JSON Schema (draft 2020-12) per document kind: film, map, cosmetic, performance, plus the shared rig, palette, soundset, path and logic. Every block has its own sub-schema. The schema is versioned with ENGINE_API and generated from the app's block classes (the same parameter declarations the runtime validates against), so the schema, the runtime and the docs can never disagree. studio.sh schema --kind map prints it, and it is also committed to the content repo at every engine bump.
• Generated block reference (docs/blocks/<block>.md in the content repo, one page per block). Each page holds:
  • what the block does and when to use it;
  • a parameter table with name, type, unit, grid, range, default and meaning;
  • its tier and gore rules, its determinism class (sim / look), its cost formula and budget, and its attach points;
  • the logic-graph sources and sinks it exposes;
  • one minimal example and one realistic example, both validated and rendered at every engine bump (the page embeds the preview still);
  • "see also" links and common mistakes.
• Stable names agents can rely on: block ids, parameter names and enum values never change meaning (append-only, §5.8). A deprecated parameter keeps working and lint warns about it.
• Where a formula may replace a constant. Every parameter row in the schema and on its reference page has an expr column (none / look / sim, §5.5a) and lists the inputs allowed for that slot. In JSON, a slot holds either a constant ("glow": 0.6) or a formula object with its mandatory fallback ("glow": { "expr": "clamp(lerp(0.2, 1, speed / 6m/s), 0, 1)", "else": 0.6 }). validate reports formula errors with the path, the character position and a fix hint ("input enemyDistance isn't allowed on a cosmetic; use speed, health, airborne, time"). lint warns when a formula is constant (fold it), or when its fallback looks very different from its typical value. preview --formulas off renders the fallback look.
• Units everywhere are explicit. Authors write metres, seconds and degrees with a unit suffix ("len": "3.85m", "at": "1.2s", "at": "72t"), and the compiler quantises them. Bare numbers are refused where a unit matters, so an agent can't confuse page units, metres and ticks.

6.2 The command interface: studio.sh and the same commands over JSON-RPC

Every command takes files or JSON on stdin and returns one machine-readable JSON result (plus a short human summary on stderr). Exit codes: 0 ok, 1 errors, 2 warnings only, 3 tool failure. The same commands are served over a local JSON-RPC socket by the running Studio (studio.sh serve, §6.5), so an agent can call them without starting a process each time.

6.3 Templates and worked examples

• Templates per kind:

  • Maps: one-screen arena, MEDIUM follow map, BIG closed map, hazard arena, logic-puzzle arena.
  • Films: round-end film, generic gun-class film, skin film, mythic.
  • Cosmetics: hat, face, outfit, aura, trail, plain weapon skin, premium skin (film + ammo + sparks + burst + feed icon).
  • Performances: emote, taunt, gloat, win dance.

  Each template is a valid document with comments in its studio.notes, and it passes the gate as is.

• The worked-example library is the proof set as reference documents. Each proof doc is annotated block by block ("this is DRIP's slab; this is how a bullet hole state is wired"), and its exact match proves it is correct. That makes them the best possible examples. More examples come with every new block (each block page links one).

• Recipes: short, validated snippets for common jobs: a door with two plates, a timed hazard cycle with a warning, lava that rises when two are left, a prop that is cast from ink and leaves a mark, a skin that pulses on a kill, a gloat that sits on the body.

6.4 The content repo layout (for agents)

stickbash-content/
  schema/<ENGINE_API>/*.json        generated, committed at each engine bump
  docs/blocks/*.md  docs/playbook/*.md
  templates/<kind>/*.json  examples/proof/*.json  recipes/*.json
  packs/<pack-id>/pack.json         the pack's manifest source (deps, channel notes)
  packs/<pack-id>/<doc>.json        one document per file
  packs/<pack-id>/sounds/*.wav      source sounds (imported by the bundle lane)
  packs/<pack-id>/takes/*.bytes     imported film takes
  out/                              previews, reports (git-ignored)

One document per file, stable key order, and studio.sh fmt to canonicalise, so diffs stay small and two agents rarely conflict.

6.5 Fast iteration: under 30 s from edit to preview still

• No Unity build for content changes. Content is data, so the same Studio player loads any document at runtime. A Unity build is only needed when a block changes (an app change).
• studio.sh serve keeps one Studio player running headless (or windowed on the Mac) with the arenas, fighters and the shape pipeline warm. It watches the content repo and hot-reloads a changed document in place, re-validating and re-compiling only that document and the ones that depend on it.
• Targets on the Mac / M2:
  • validate + compile < 1 s;
  • hot reload < 2 s;
  • a preview still at a given tick < 10 s;
  • a 6-still contact sheet < 20 s;
  • edit → first still < 30 s;
  • a 10-second mp4 < 60 s;
  • play with 3 bots for one round < 90 s (fixed-step fast-forward where perf isn't measured).
• On the VM, still and video runs go to the M2 / Mac lanes by the existing load rules, and validate / lint / logic checks run locally.
• Deterministic seeds everywhere: every preview, play, gate and diff takes --seed and prints the seeds it used. The same seed, document and engine build give the same frames and metrics, so an agent can compare before and after a change and trust that the difference is its own edit.

6.6 The agent playbook

docs/playbook/ in the content repo holds one page per kind (map, film, skin, taunt), each a numbered checklist the agent follows:

1. Read the brief.
2. Pick a template or a proof example.
3. List the blocks to use.
4. Write the document.
5. validate until clean, then lint until clean or each warning is justified.
6. explain and compare the summary with the brief.
7. preview the key moments.
8. play (maps: 2 / 4 / 8 bots, every pace) and read the metrics against the targets on the page.
9. gate --fast.
10. diff against the last revision.
11. Write the check sheet (stills, metrics, gate).
12. publish --channel test and request approval.

Each page also lists the kind's look rules, taken from the existing taste notes (e.g. USER_TASTE.md and the cinematic and realistic action direction for films), the fairness rules for maps (warnings, spawn distance, no unwinnable spots), and the no-advantage rules for cosmetics. These are rules an agent can check, not taste it has to guess.

6.7 Ready for freehand drawing and posing later (no data-model change)

• Drawing produces the data that already exists: shape primitives and paths (points on the mm grid) inside rigs. A freehand stroke is saved as a simplified path plus stroke width and fill. There is no new block and no new document field.
• Posing produces perf.pose keys (taunts) or a film.take (films), the same 13-joint, 60 Hz format the kill pages bake today. A posed take and an imported take are the same data.
• Editor-only data (layer names, guides, onion-skin settings) lives in the document's studio block, which the compiler strips. Adding a tool never changes a pack.

7. NEW BLOCKS BEYOND TODAY'S GAME

In plain words. A pushed item can only use bricks that are already inside the app. If a brick is missing on launch day, no item can use it until the next app update. So the launch app carries today's bricks (§5.2) plus many new ones the game has never had: moving and spinning platforms, switches and doors, portals, lasers and saws, spawners, rising water, weather, new camera moves, new skin materials, skins that react when you hit or win, and taunt props. The logic graph (§5.5) lets us wire them together into behaviours nobody has built yet, such as a door that opens when two players stand on two plates, or lava that rises faster when only two fighters are left [user, 6 Nov]. DECIDED (D1, 6 Nov) [user]: the launch app carries today's blocks plus the ~61 T1 blocks below (option A).

7.1 Rules every new block follows

• Ranked by value. "Value" means how many new items the block unlocks, times how much players notice it, divided by build and risk cost. T1 = the recommended launch library. T2 = the first app update after launch. T3 = later, or only if a design needs it.
• Online. Each block is either sim (it changes the match: host-authoritative, state in the snapshot through the generic writer, its pose a pure function of (state ints, tick)) or look (drawing and sound only, run per phone, never hashed) (§5.7). A sim block that pushes or carries fighters must be predictable: its force or motion is a pure function of (position, state, tick) that the client can run for its own fighter, as MapEvent.Accel already is for gusts (MapEvents.cs:185). A sim block also declares its bot rule (avoid, wait for a phase, ride, use) so NavGraph and the bots handle it.
• Fairness. Every harmful sim block has a warning of at least 0.6 s (the gate checks it), follows the room's HAZARDS switch, and is spared during kill films and executions, as today's hazards are. Cosmetic look blocks keep the no-advantage rule: hard caps on size, alpha and screen area, never on or near the hitbox, and no information a player wouldn't otherwise have.
• Budgets. The numbers below are starting caps on the LOW reference phone: host CPU per fixed step for sim, and shapes per frame for drawing. Stage 1 (and each engine's stage) calibrates them so that a map's or film's engine blocks together never cost more than today's heaviest code map (Pinball / Wrecking Yard) or heaviest film at each tier. After that the gate enforces them (§5.12), and the phone's budget meter drops look extras first.

7.2 Maps: new elements and logic

Logic examples the T1 set makes possible, with no new code: a door that opens only while two plates are held (zone ×2 → AND → door); a "last two standing" finale where lava rises and lasers start (alive count ≤ 2 → latch → level + laser); a switch that reverses every belt and spins the rotors the other way (switch → toggle → belt + rotor); a vault that opens after a sequence of three targets is hit in order (switch ×3 → sequence → door → spawner); a seeded random event every 30 s (timer → select(random) → dropper / spikes / field gust).

7.3 Films: new camera, effects, time, sound

All film blocks are look. A film's sim part is only its end pose and the victim's death state, and the gate checks that no new block changes them (§5.7).

7.4 Skins and cosmetics: materials, patterns, reactions

All are look, under the no-advantage caps (§7.1). Materials and patterns need one app-shipped feature in Shapes.shader (layers, gradients, pattern functions). That is a shader change in the app, precompiled at build, and packs only set its numbers [user constraint: no shaders in packs].

7.5 Taunts and emotes: layers, props, FX

The taunt start stays host-decided: Ev.Taunt carries a ContentRef and poses arrive in the snapshots (Taunts.cs:13-15). Props and FX are look.

7.6 Shared blocks

7.7 Counts and cost

The T1 set is about 35-45 lane-days of the plan, spread over the engines that own each family (§10). T2 adds about 15-20 more.

8. The proof set

The proof set is built in the engine only to prove it can match the originals exactly. Players keep the originals [user]. Each pick covers different blocks, so together they exercise every family in §5.2 before launch.

8.1 What "exact match" means (DECIDED, D7: identical)

The rule (D7: zero difference per frame in shapes, sounds and positions): for every proof item, for every gore level and tier and for a fixed seed, the engine version and the original are run on the same machine at the same gore level. They must produce

• the same full state on every tick: maps: pieces, hazards, props, event phases, director draws; films: both bodies' joints, the end pose, cuts and pieces. Cuts are allowed here because both sides use the same gore level. This is a local comparison, not the online hash;
• the same draw list (the shapes sent to ShapeBatch, compared after the same quantisation) on every sampled frame, with a pixel fallback (SSIM ≥ 0.99 on the whole frame) only where an ordering difference doesn't change the image;
• the same sound events (voice id, tick, vol, rate) and the same Rng draw counts.

Online, each engine proof film and map also passes a host + client run (Mac host, phone client) with matching online hashes (§5.7). studio.sh diff prints all of this per item. It is stricter than the PORT GATE's page parity (2 page units, region SSIM ≥ 0.50), because here both sides are the same game.

8.2 Three maps

Alternate, if the user wants weight-driven physics in the set: swap Belt Line for Seesaw Pier (a plank tipped by the weight on it, spring + damping + caps, the sea as ring-out).

8.3 Six films

THE OFFERED HAND also has a fire variant in its own file (PageKills/TheOfferedHandFire.cs). The proof rebuilds the main one, and the fire variant becomes an engine variant of the same document once the main one matches.

Every film should also prove its GLOAT hand-off (film.handoff) and HIGH NOON should be checked on every gun class whose track ships.

Not covered by these six and left for after launch: a film with a room rule tied to a real wall or ceiling (13 films, e.g. the portal film). film.fit has the surface rule from day one, but its exact match waits for a seventh proof film [call].

8.4 Skins and cosmetics

8.5 Taunts and emotes

8.6 Blocks the proof set doesn't reach

The proof set proves that the engine can match the originals exactly. It can't reach every block. These are covered by a block test suite at the gate instead: one small scenario per block, run like the proof, that checks the block's own behaviour, determinism and budget.

• Blocks with no proof item: map pads / lifts / carts / low-g, map.liquid, the push / magnet / damage hazards, path / pivot / crumble pieces, the legacy hazard flags.
• All the §7 new blocks, which have no original to match.

For a block that does have a built-in user (e.g. Seesaw Pier for weight-driven pivots), the test compares against that map's own scenario.

9. Risks

10. Build order and sizes (sequential engines)

The user (6 Nov): "u build one by one, first map engine, then animation engine, like that" [user]. Each engine is finished end to end, with its blocks, its proof items identical, its gates, its online play, its Studio editing (agent-first, then visual) and its playbook, before the next one starts. The full task list is docs/superpowers/plans/2026-11-06-content-engine.md.

Total: about 174-212 lane-days (about 200-243 with review rounds). That is about 10 % more than building everything interleaved, the price of finishing one engine at a time.

Calendar:

Protocol: each engine adds its wire messages with one bump (145 maps, 146 films, 147 skins, 148 taunts). This is allowed only because no player builds exist before launch, and the launch build carries the last number [call].

11. What launch needs

Launch waits for the engine, the Studio and the proof set [user]. Concretely:

1. All four engines (Stages 1-5, each passing its own done definition) in the store build: ENGINE_API = 1, every block family of §5.2 plus the ~61 T1 new blocks (§7, D1), the final protocol number, and the shared catalogue serving built-ins and packs (Stage 6).
2. The proof set exact (§8.1 report green): 3 maps, 6 films, 6 cosmetics, 4 performances, all on the internal channel only (players keep the originals). Every new block also passes its block test (§8.6).
3. The agent interface (Stage 1, grown in each stage; §6) on the VM / M2 / Mac, meeting the < 30 s edit → still target, and the Studio v1 (each engine's editing + the Stage 6 polish) on the Mac. At least one item of each kind is made end-to-end by an agent following the playbook, through gate → approval → the test channel.
4. The pipeline live: sbapi content, content.stickbash.com, the content list and kill list, signing, human-only approval, rollout, and a rollback + cascade drill done.
5. Store: review notes written, the first submission accepted with the engine in it.
6. At least one real new item (a skin or a taunt) pushed to test and then live after launch day, to prove "no app update" in production [call].

Not needed for launch: migration of any old content, player creation, the seventh (room rule) proof film, a second CDN origin.

12. Left to the builder [call]

• The binary layout of compiled documents (follow pk_pack2.py's style: varints, string table, deflate).
• The exact per-block cost formulas and per-tier budgets, measured in Stages 1-5 on the reference players.
• The Studio's UI layout, built in the game's own look.
• The content repo layout (one folder per pack, one JSON per document, sounds beside them).

DECISIONS FOR THE USER (all DECIDED)

The numbering follows the coordinator's asking order (D1 … D15). All 15 were decided on 6 Nov; the design is APPROVED.

1. How many new building blocks go into the launch app? Pushed items can only use blocks the app already has. A block we leave out can't be used until the next app update.

   • DECIDED (6 Nov): (A), today's blocks plus the ~61 T1 new blocks.
   • (A) Recommended: today's blocks plus about 60 new ones (§7, the T1 list). That is about 23 for maps (moving and spinning platforms, switches and doors, portals, lasers, saws, crushers, spikes, falling objects, spawners, rising water and lava, wind and gravity zones, weather, and the wiring that combines them), 16 for films, 8 for skins, 6 for taunts and 8 shared. Launch is about 10-13 weeks away.
   • (B) Everything in (A) plus the next 12 (T2: score zones / king of the hill, creatures, x-ray and lens effects, dangling capes and tails, walking taunts and more). Launch moves about 3-4 weeks later.
   • (C) A smaller start: today's blocks plus about 5 new ones per kind (around 25). Launch is about 2-3 weeks sooner, and more new ideas wait for app updates.
   • (D) Today's blocks only. Launch is about 8-10 weeks away, and anything new needs an app update.

2. Can an item made by an AI helper reach players without a person approving it? Every item passes all the automatic checks first.

   • DECIDED (6 Nov): (A), a person (you or the lead coordinator) approves, and the server enforces it.
   • (A) Recommended: a person (you, or the lead AI coordinator on your behalf) looks at the item's check sheet and taps APPROVE before players get it. Helpers may send items to our own test phones on their own. The server enforces this: only a person's dashboard login can approve.
   • (B) Passing the checks is enough. Helpers publish to all players themselves.
   • (C) Only you approve, item by item.

3. How complete must the Studio (our Mac creator app) be at launch?

   • DECIDED (6 Nov): (A) at launch. Freehand drawing and posing come in a later Studio update, with no data change (§6.7). The user: AI agents will build ~95 % of content, so the agent interface comes first (§6).
   • (A) Recommended: it works for all four kinds (maps, films, skins, taunts). You can open an item, try it in a real match against a bot, change any setting, set poses and timing on a timeline, wire map logic, run the checks and publish. No freehand drawing tools yet: shapes are typed in or imported.
   • (B) Everything in (A) plus freehand drawing for shapes and a drag-the-stickman posing tool. Launch moves about 2-3 weeks later.
   • (C) Only the helpers' typed commands and a preview window at launch. The visual editor comes later.

4. A friend joins an online room that uses a new map or film they don't have yet. What happens?

   • DECIDED (6 Nov): (A) + (C). The app downloads new content at the splash with a progress bar before the menu, continues with cached content if offline, and rooms download a missing pack with a progress bar before joining (§5.13).
   • (A) Recommended: their phone downloads it first, then they join. A progress bar shows the wait: a second or two for most items, longer for an item with new sounds.
   • (B) The room only picks maps and films everyone already has, so nobody waits.
   • (C) They can't join until they download it themselves.

   (Their friends' new outfits are never a problem: they download in the background, and a plain default look shows until then.)

5. When does a phone download new items?

   • DECIDED (6 Nov), settled by D4: at app open, on any network, blocking with a progress bar. The size cap of D6 applies.
   • (A) Recommended: quietly in the background when the game opens, on any network. Most items are tiny because the art is drawn by the game itself, not pictures.
   • (B) Only on Wi-Fi.
   • (C) Only when the player opens that item or joins a room that needs it.

6. How much space may downloaded items take on a phone?

   • DECIDED (6 Nov): (A), at most 5 MB per pack and 150 MB in total, with LRU eviction; owned items are always kept.
   • (A) Recommended: at most 5 MB per pack and 150 MB in total. Packs not used for a while are deleted and downloaded again if needed. Items a player owns are always kept.
   • (B) Tighter: 2 MB per pack, 60 MB in total.
   • (C) No limit.

7. How exact is "exact" for the proof set?

   • DECIDED (6 Nov): (A), identical: zero difference per frame in shapes, sounds and positions.
   • (A) Recommended: identical. The computer compares every frame's shapes, sounds and positions with the original and finds no difference.
   • (B) No difference you can see side by side. Tiny invisible differences are allowed.
   • (C) Same look and feel. Small visible differences are allowed.

8. Are these the right proof items? Maps: Backyard, Belt Line, Wrecking Yard. Films: SIX-SHOOTER, THE X, DRIP, HIGH NOON, COLD-BLOODED, THE OFFERED HAND. Cosmetics: the ICE revolver, one PLAIN skin, the HOODIE outfit, the CROWN hat, the FIRE aura, the RAINBOW trail. Taunts: LOSER, CHAI BREAK, DAB, BHANGRA.

   • DECIDED (6 Nov): (A), as listed, with the HOODIE.
   • (A) Recommended: yes, as listed.
   • (B) Yes, but swap Belt Line for Seesaw Pier (it tests a plank that tips with players' weight).
   • (C) Add more films (8-10) for wider coverage. Launch moves about a week later.

9. How do new items reach players?

   • DECIDED (6 Nov): (A), our test phones → 10 % for a day → everyone, with a one-tap pull-back at every step.
   • (A) Recommended: our own phones first, then 10 % of players for a day, then everyone. Any step can be pulled back in one tap.
   • (B) Our own phones first, then everyone.
   • (C) Everyone at once.

10. Where does the movement of new kill films come from?

    • DECIDED (6 Nov): (A), motion from the kill pages; the Studio adds props, camera, sound and the gore levels.
    • (A) Recommended: as now, from the kill pages we already make in the browser, brought into the Studio. The Studio adds props, camera, sound and the gore levels.
    • (B) Posed directly in the Studio from the start.
    • (C) Both from day one. More to build before launch.

11. Must every new kill film be made at all three gore levels?

    • DECIDED (6 Nov): (A), all three gore levels authored.
    • (A) Recommended: yes. The maker builds LOW, MEDIUM and EXTREME (as today), and the checks play each one.
    • (B) The maker builds EXTREME only, and the game works out MEDIUM and LOW automatically. Faster, but less control over how the lower levels look.

12. Should content be allowed small formulas? Some effects would be quicker to describe with a formula, for example "glow gets brighter the faster you move".

    • DECIDED (6 Nov): (B), the user overrode the recommendation: a tiny bounded formula set (§5.5a) with a server kill switch to constants.
    • (A) Recommended: no formulas. Only the fixed blocks, curves and wiring. This is the safest reading of the app-store rules, and a missing ability becomes a new block in an app update.
    • (B) Allow a tiny fixed formula set (add, multiply, min, max, no loops). More flexible, with a small app-review risk.

13. We pull a broken item that players have bought. What do they keep?

    • DECIDED (6 Nov): (A), they keep it: it rolls back to the previous good version, or is hidden until the fix if there is none, then returns by itself.
    • (A) Recommended: they keep it. It goes back to its previous good version, or is hidden until the fix if it had none, then comes back by itself.
    • (B) It is hidden until the fix (still owned), even if an older good version exists.
    • (C) We refund their gems as well.

14. Where are the download files kept for players?

    • DECIDED (6 Nov, the coordinator's technical call): (A), our server behind the Cloudflare cache, immutable files. The setup still to do is listed in §5.13.
    • (A) Recommended: on our own server, behind Cloudflare's worldwide cache. Files never change once published, so the cache serves almost every download. Low cost, nothing new to set up.
    • (B) Cloudflare R2, a paid storage service. Our server does no work for downloads, at a small monthly cost per use.
    • (C) Google's storage (Firebase). Works well, but it is a separate bill and another account to manage.

15. Where do the designs and sounds we make live?

    • DECIDED (6 Nov, the coordinator's technical call): (A), a new private repo stickbash-content.
    • (A) Recommended: in their own new private project on GitHub ("stickbash-content"), apart from the game and server code. Helpers can make content without any risk of touching code.
    • (B) Inside the server's project.
    • (C) Inside the game's project.