The ticket grid (#3773) surfaces a split nobody can see from a single screen: a ticket carries TWO independent answers to 'which capability does this advance?' 1. WorkItem.capability - free text on the board, written at filing/wrap-up by the #3670 flow and by 'ticket_cli edit --capability'. 2. Capability.ticket_numbers - the features registry's first-class membership edge, written by hand in the ticket grid (#3667/#3717). Observed on #3773 itself while building the grid: the board said capability='Feature Attribution Workflow' while the grid's Capability cell was EMPTY, because the registry had no ticket_numbers edge for it. Both are 'the capability', both look authoritative, and neither reads the other. Consequences: the #3670 attribution ritual (asking the operator to name the feature at claim time) produces data the timeline and receipt never see, since those read the registry. And the grid's editor silently disagrees with what the card shows. DECIDE, then build one of: (a) the registry edge is the truth and WorkItem.capability becomes a WRITE-THROUGH - 'edit --capability' maps the ticket in the registry (minting by title, exactly like name_tickets does today), and the board field becomes a cache/mirror; (b) the board field is the truth and the registry derives ticket_numbers from it on read; (c) keep both but SHOW both in the grid, with a one-click 'adopt the board's answer' - the cheapest honest version. (a) is the likely answer: the registry already owns the commit join and the move/split semantics that make re-mapping one action. Whichever wins, the grid should stop being able to show blank while the card shows a name.

A ticket number is the durable handle everyone uses — chat, PR bodies, commit subjects, receipts — but there is NO URL that opens ticket #<n>. Verified: the board route (/c/{cid}/project/{pid}/kanban) accepts only group_by; the modal route (/kanban/item/{item_id}) is keyed by internal UUID and returns a bare fragment (no shell — hx-* attributes dead when navigated directly). Consequence: links to tickets from anywhere outside the app either don't exist or point at the wrong system (chat sessions have been linking #<n> to GitHub, which is not where tickets live). BUILD: 1. /c/{cid}/project/{pid}/kanban?ticket=<n> — full shell-wrapped board page that resolves the NUMBER to its item (WorkBoard.get_by_number) and opens that card's modal on load. Number not found -> board loads normally with a small "no ticket #<n>" notice, never a 500. 2. Honour the existing coordinate/history conventions: the URL must be shareable and refresh-stable, play nice with the htmx shell scope, and not push duplicate history entries (see the coordinate-routes rule from #3495: never push the URL the browser is already on). 3. A short alias worth having while in there: /t/<n> (company/project resolved from active context) -> 307 to the full URL, so a bare number can be linked from anywhere. 4. Surface it: a copy-link affordance on the modal header, and ticket_cli show prints the URL. 5. Consumers to update once it exists: PR bodies and receipts/timeline (#3610/#3667 lanes) link ticket numbers to this URL — the receipts' evidence trail should land people on the board, not on GitHub. ACCEPTANCE: pasting /c/cgl/project/ppe/kanban?ticket=3670 into a fresh browser opens the board with #3670's modal open and working (htmx alive); /t/3670 redirects there; unknown number degrades politely; the modal offers copy-link.

Tom: 'the receipt view is interesting — but that data could be integrated into the timeline. Until clients ask for specific views, simpler = better; the timeline does most of the jobs once hydrated.' Design task: bring the receipt's per-capability numbers (derived effort, sittings, active days, commit count, coverage context) INTO the timeline — likely the lane card's tooltip or an expanded card state — so one surface answers both 'when' and 'what it took'. Keep the receipt route alive until the fold proves out, then retire it from the header entirely. Honesty rules carry over: ~ marks derived, reported hours never summed with derived, no delivery claims.

Tom: "Filtering will be big — it's how executives will see the work they care about easily, and how I as the studio architect create specific reports that are meaningful. We likely want a pretty well-featured filtering system — even the ability to save filters. For example: just the Unreal Engine features that were built this week." The #3768 v1 (comma-OR text terms over title/tickets/subjects) is the seed. The full system: 1. FACETS, composable with text terms: - date range (filed/active within: this week, last 2 weeks, custom from-to) — "built this week" - area/App (from member tickets' area_id -> tool label, the derivation that already exists) - type (feature vs bugfix vs chore — change_type majority, the #3768 glyph logic) - repo (alchemy/cookbook), status (has unexplained / all-explained), person (when multi-user) Grammar suggestion: keep the one text box but support tokens ("app:unreal filed:this-week type:feature ue rig") so power use stays one line and the URL stays the state. 2. THE URL IS THE FILTER STATE (composes with #3671 ticket deep links): every filter combination is a shareable link — sending an exec "the Unreal work this week" is sending a URL. This is the cheap version of reports; build it before any report builder. 3. SAVED FILTERS: name a filter ("UE — this week"), it appears as a chip row on the timeline header; relative dates stay RELATIVE when saved (this-week means the week you open it, not the week it was saved). Storage: the feature registry (a top-level saved_filters key, round-trip-safe like capability_naming). Saved filters ARE the meaningful reports — the exec clicks a chip. 4. Same honesty rules: hidden-lane count always visible; a filter that matches nothing says so and offers clear; relative dates label themselves with the resolved range. SEQUENCING: after #3667's evidence grows (filters are only as good as the tagging) and ideally after #3671 (URLs) so saved filters land shareable from day one.

The cookbook's semantic arc is start -> build -> render -> review -> publish. A beat board (scr) has build, publish, shelves and context-menus - and NO render recipe at all. There is no alchemy/render/scr. CONTRAST, WHICH IS THE SPEC: alchemy/render/svz already carries RenderAnimatic.py, ExportOtio.py and ExportPremiereTimeline.py. A film scene can render its assembled timeline to a watchable animatic, hand an OTIO to editorial, and round-trip a Premiere timeline. A beat board - which is now a first-class timeline owner (#1024) with its own cast registry (#1025) and its own previs - can do none of those. The board is authorable and buildable but not watchable. WHAT TO BUILD: alchemy/render/scr, mirroring the svz render leg against the board's own timeline (the one timeline_for(po) now resolves via TIMELINE_OWNERS): render the assembled beat board to an mp4 animatic with its voice track, and export its OTIO. DECIDE AND STATE: * Whether the svz render steps generalize to any timeline owner rather than being copied. They read a ScriptScene timeline, which is exactly what a board now hands back - copying them would re-bake the svz assumption one layer over, which is the mistake #1024 exists to stop. * Where a board's animatic lands, and whether it becomes the board's reviewable media (the review/turntable fold). OUT OF SCOPE: the previs 3D render path; MagiCam. NOT THE FIX FOR THE MISSING PREVIS AUDIO - see notes.

Ensures all video clips on V1 don't have linked audio. THis makes for clean nesting/naming.

The Premiere UXP API (ppro, used by alc/plugins/premiere/bridge) exposes no unlink verb, no menu-command executor, and no link-state accessor (verified across all classes, live instances, Utils, and Constants). This blocks automating the 'Unlink V1 Clips' amc-publish step needed for clean video-only nesting in EnsureShotNames (createSubsequence otherwise drops blank audio clips on placement). ExtendScript/QE DOM via CEP CAN unlink A/V. Extend the premiere bridge to optionally run ExtendScript so Unlink (and other UXP-gap ops: link-state read, menu commands) become scriptable. For now the artist unlinks V1 by hand and UnlinkV1Clips is a detect-and-warn check.

manifest.py writes shot media as render-dir-relative strings (e.g. 'shots/INT_1000/INT_1000.mp4', 'shots/INT_1000/INT_1000.%04d.png'). These are NOT PathObject-relative, so ingest needs bespoke path-cobbling to rebuild the abs path. On a film there are millions of paths; anything outside structure multiplies glue code. Add an amc pathmap so each shot's quicktime + png-sequence resolve as PathObjects, and store them as alchemy-relative paths that add_root() reconstructs to abs on any network/remote machine. MSD path fields should ALWAYS be add_root-relative. Update manifest.py + declare PATH_FIELDS so msd_abs() absolutizes them.

An asset resolved from a NON-active project store must save back into that project. Today asset.save_standalone() resolves its write path from the global active company/project, so a script that does PROJECT_REGISTRY.get_project('loj', company_id='cgl') and saves a character writes the profile into whatever project happens to be globally active instead.

TemplateFamily slots (TXT_HEADLINE, IMG_LOGO) are typed but have NO geometry - the layout lives inside the .aep comp, so nothing outside After Effects can say where a template's headline sits. Add normalised slot rects to TemplateLayout (x/y/w/h as fractions of the variant frame, per slot), have the After Effects bridge read each comp's layer bounds per variant and write them back into the family manifest, then extend the transcript editor's preview guide layer (#trs-guide-layer, initPreviewFrame in app/tools/transcript/static/js/transcript_editor.js) with a 'Template' guide source alongside the existing delivery-variant safe zones - pick a family + variant, see its title/logo boxes over the shot.

Make the aggregated registry and the standalone profiles stop disagreeing, by fixing the write side rather than papering over it on read. Today the two halves are inconsistent: * SAVE writes the standalone profile ONLY. `AssetBase.save_standalone()` (alc/models/script/models/manifests.py:748) is what every asset edit calls -- app/routes/assets.py:349 (env/prp/drs dashboard), :409 (character dashboard), :458 (the /height endpoint), plus the prep band and the AI analysis passes. Nothing writes prp.json / env.json / drs.json / chr.json alongside it. * LOAD treats the aggregate as the KEY INDEX and the standalone as the VALUE. `PropRegistry.load` (manifests.py:1121-1128) and its three twins (EnvironmentRegistry:1298, DressingRegistry:1198, CharacterRegistry:1013) iterate `registry.props.items()` parsed from the aggregate, then overwrite each entry from `<id>.json` when that file exists. Two consequences, one cosmetic and one sharp: 1. Field values in the aggregate go stale and are simply wrong on disk. Harmless at read time, because the standalone override wins -- but the file is a lie to anything that reads it directly (a farm job, an external tool, a human). 2. THE REAL BUG: because the loop only visits keys present in the aggregate, a standalone profile whose id is MISSING from the aggregate is never read at all. The asset silently does not exist to the app -- no error, no log line, it is just gone. That makes the aggregate load-bearing for existence while being unmaintained on write. It is not a cache you can regenerate; it is a second source of truth that nothing keeps in sync. Fix direction (implementer's call, but the constraint is: one write path): either have the asset save paths update the aggregate too, or drop the aggregate's index role so that load() enumerates the standalone profiles on disk and uses the aggregate only for records that have no profile. Whichever way, after the change it must be impossible to create a standalone profile that the app cannot see. Acceptance: * Saving an asset leaves the aggregate and the standalone in agreement -- no second step, no manual resync. * A standalone profile with no matching key in the aggregate is still loaded and still appears on the Props / Set Dressing / Environments dashboards. * Round-tripping a registry does not drop unmodelled keys (see notes -- tnt/chr/chr.json).

Stamp the BEAT ID onto the exported timeline's cells, in both the .otio and the FCP 7 XML, so a cut that comes BACK from Premiere can be matched to the board it came from. == WHY NOW =============================================================== #3235 gave every exported cell a beat id in the Alchemy model (TimelineItem.metadata ["beat_id"], on clips AND gaps) and used it to make todo reconciliation a join rather than a diff of free text. That worked. But the id dies at the serializer. OtioAdapter.gap_to_otio() builds an otio.schema.Gap with name + source_range and no metadata; the board's clip branch in item_to_otio() (the `item.media_url and not item.manifest_relative_path` case) builds an otio.schema .Clip with name + media_reference + source_range and no metadata. Compare clip_to_otio(), which DOES carry `metadata={"alchemy": meta}` for manifest-backed clips -- the board's cells simply never take that path. So today the deliverable an editor opens has no stable handle on any beat. Clip NAMES carry the block id or the first 40 characters of the description, both of which change when someone edits the board. == WHAT IT SHOULD DO ===================================================== 1. Carry `beat_id` (and whatever else identity needs) into the OTIO clip/gap metadata under the existing "alchemy" namespace, so the .otio round-trips it natively. 2. Get it into the FCP 7 XML too. FCP XML has no metadata element, so this needs a decision -- a <comment>/<labels> field, a marker, or an encoding in the clip name. Whichever it is, the requirement is that PREMIERE PRESERVES IT across a re-export from Premiere's own side. Verify that rather than assume it: a field Premiere drops on save is worse than no field, because it looks like it works. 3. Read it back. otio_gap_to_internal / the clip recovery path already recover "alchemy" metadata for manifest-backed clips (see otio.py's "Recover Alchemy-specific metadata" block); the board's cells need the same. == THE TENSION, STATED SO IT IS DECIDED AND NOT DISCOVERED =============== #3235 rejected text cards partly because they "put work-tracking information inside the deliverable". A beat id looks like the same category of thing. It is not, and the distinction is worth writing down: a text card is a TASK smuggled into a picture -- it describes work, it is visible, and it has to be replaced. A beat id is IDENTITY -- invisible, describes nothing, and is what makes a round-trip possible at all. Every NLE interchange format carries ids for exactly this reason. But it IS a decision, and Tom should make it before anyone builds: does the deliverable get to carry Alchemy's ids? == WHAT THIS UNBLOCKS ==================================================== Tom, while testing #3235 in Premiere: "i'm going to want to do things like update the editor from premiere ... so there's parity there." Parity means what goes out has to be identifiable when it comes back. The obvious first round-trip is TIMING -- an editor re-cuts in Premiere, and the beats' screen_secs follow, which is a clean mapping because screen time is already the authored quantity the lanes are laid out against (#3235). Without a beat id that reconciliation would have to guess from clip order, which breaks the moment anybody inserts, deletes or reorders a shot -- i.e. the moment anyone actually edits. The Premiere bridge already exists (alc/plugins/premiere/bridge/server.py, the UXP panel) and already publishes a sequence back as OTIO (#321 / the amc publish chain), so the transport is there. The missing piece is the join key. == SCOPE ================================================================= This ticket is the KEY ONLY -- stamp it, ship it, prove it survives Premiere. The actual "update the board from a Premiere cut" feature is its own ticket and should not start before this one lands.

Build a proper camera/sensor model as the real backing for the camera-body library (supersedes the hand-seeded 10-body stopgap in alc/config/cameras.py from #263). SOURCE DATA already exists: C:/Users/tmiko/PycharmProjects/storyforge/resources/cameras - 214 JSON files exported from the VFX Camera Database (vfxcamdb.com), each with {camera_make, camera_model, sensor_type, shutter_type, sensor_modes:[{resolution:[w,h], sensor_area_mm:[w,h], aspect_ratio}]}. A camera has MANY sensor modes (open gate / S35 / 16:9 / anamorphic), so the model is body + modes, not a single sensor size. MODEL: a normalized pydantic CameraBody/SensorMode in alc/models/camera/ (__init__.py is empty; query.py already holds a vfxcamdb scraper + CameraSpecs string-parse model - reconcile: scraper = acquisition pipeline that produced the storyforge JSONs, new model = clean runtime shape; dedup/merge, don't leave two camera models drifting). INGEST the 214 JSONs into an Alchemy resource/config location as the library data. CONSUMERS: #263's get_camera_bodies/set_camera_body point at this model; picking a body AND a mode yields the CineCamera filmback (sensor_area_mm) AND optionally the render resolution; Camera Caddy Camera Body dropdown gains a mode sub-select. Resolves the BP_MagiCam filmback caveat (#258) with real per-mode sensor data instead of nominal values.

IngestManifest.commit() creates the version via create_empty_version() and copies sources with shutil.copy2(), but never registers the asset in its category registry (chr/env/prp/drs). It bypasses TaskManifest.commit, the only caller of register_asset() (the single registry writer). Fix: after each commit group's create_empty_version() succeeds, if entity_type=='assets' and parent in {chr,env,prp,drs}, call register_asset(self.project, group['parent'], group['child'], label=...). Honor the choke-point contract (idempotent, single writer). Note register_asset is guarded to CFG.project, so confirm the ingest commit runs with the target project active, or lift that guard for the ingest path. Real example: bse/imm chr 'ziya' was ingested but only showed up in the browse because a later scr publish happened to register it.

alc/models/work_item.py::resolve_candidate_files reads the feature registry from a hard-coded absolute path (E:/Alchemy/cgl/ppe/PUBLISHES/msd/features/registry.json) and does so synchronously on every hydration. Resolve it through the taxonomy layer's features_root()/registry.json helper instead (as PR #26 already did for the sibling read it touched), so it is portable across companies/projects and not pinned to the ppe board. While here, consider whether the per-hydration synchronous read should be cached. Surfaced during the cookbook sprint (PR #26).

Durations should be carried as whole FRAMES. An int cannot be got wrong by a rounding error; a float second can, and did (the row-select bug on Create Script: two clips whose seconds rounded opposite ways ended up overlapping by one frame). WHAT IS ACTUALLY THERE NOW (alc/models/edit/models.py:15) class RationalTime(BaseModel): value: float # The frame number or elapsed ticks count rate: float # (e.g. 24.0, 30.0, or 1.0 for straight seconds) Two problems in three lines: 1. value MEANS a frame number but is TYPED float, so nothing stops a fractional frame being stored. Today every producer happens to pass an int-valued float by convention - except alc/models/edit/otio.py:582 (FCPXML rate conform, value=rt.value * scale), which yields genuine fractional frames on a 23.976<->24 conversion. 2. rate=1.0 is documented to mean the value is straight SECONDS. So the same field means frames at 24 and seconds at 1 - one field, two currencies, and no way for a reader to know which without inspecting rate. WHAT TO DO - Type value as int and validate it on construction (reject/round explicitly, don't silently truncate). - Give the float->frame conversion ONE home: a RationalTime.from_seconds(seconds, fps) classmethod that rounds once. Callers stop doing round(x * fps) inline (14 construction sites today) - so a rounding rule can never differ between two of them, which is exactly how the overlap happened. - Decide what rate=1.0 means and stop overloading: either seconds get their own type/field, or 'seconds' stops being expressible here. - Real-media durations (a wav is 1.8734s, STT word times are float seconds) legitimately arrive as floats: quantize at the BOUNDARY where they enter a timeline, and keep everything downstream integer. - Audit the FCPXML rate conform for the fractional frames it can produce. DONE WHEN: RationalTime.value is an int, there is exactly one seconds->frames conversion in the codebase, and a test pins that a ragged (non-frame-aligned) input still yields butt-joined integer spans.

A beat board's previs now imports both MagiCams and voice - and they run on different clocks. Picture ends at frame 485 while the last board holds for ~19 seconds with five more voice clips playing under it. THREE TIME BASES FOR ONE BOARD, all emitted by the same to_script_model() manifest: * audio_track - 16 clips, 933 frames total (MEASURED voice lengths) * storyboard_track - 14 clips, 808 frames total (also voice-timed) * blocks duration_frames - 16 blocks, 622 frames total (AUTHORED estimate) * scene.duration_secs - 25.91s (~622 frames), agreeing with the estimate and with neither track magicam times the camera cuts from the block estimates: the MagiCam marker deltas are 53, 26, 20, 43, 14, 48, 48, 38, 26, 43, 35, 39, 51 - an exact match for block.duration_frames. The audio strips are laid on the measured base: 68, 61, 44, 58, 40, 57, ... which is what storyboard_track also uses. So the cut points and the voice can never line up. DECIDE AND STATE - THIS IS THE WHOLE TICKET: which clock is authoritative for a board. * MEASURED voice wins: a beat's picture holds exactly as long as its line takes to say, and duration_frames becomes a pre-recording estimate that the rendered take supersedes. This is what an animatic normally means, and storyboard_track already agrees with it. * AUTHORED estimate wins: the board's timing is a deliberate creative statement and audio gets trimmed or padded to it. Pick one and make every consumer read it. Do NOT leave two tracks disagreeing and let each consumer choose - that is the defect. ALSO: scene.duration_secs must follow whichever wins - the prep band and the schedule read it, so a board whose picture and duration disagree misreports its own length. DONE WHEN: a board's previs plays picture and voice on one clock; the MagiCam markers and the sound strips agree; and scene.duration_secs matches what the previs actually is.

Previs exports ONE MagiCam per beat. On the theaxe board that gave 14 cameras where roughly 6 boards are one continuous setup - successive drawings of the same shot, not 6 shots. The result over-complicates the scene and the artist has to reconcile 6 cameras that should have been one. MAGICAM ALREADY DOES THIS - it was built for TVPaint that way. cookbook/../magicam/blender/build.py loops the clip's LAYERS into image_plane_01..10 under a SINGLE camera, and set_key_frames() keys the image sequence over time. One camera, many drawings, keyed. The capability is not the gap. THE GROUPING ALREADY EXISTS TOO - AND NOTHING READS IT alc/models/edit/models.py:1283 declares alongside , and models.py:89 defines a Shot clip - 'a shot segment on the shots track', carrying shot_type and its own clip_range. ScriptScene._build_shot_track() (script.py:512) already SEEDS it: a run of consecutive action blocks becomes ONE shot, each dialogue block its own shot - derived from the effective voice track so it stays frame-aligned. already means a human committed manual cuts and those win over the derived ones (script.py:586-596, 714-715). And magicam explicitly THROWS IT AWAY: magicam/alchemy/models.py:118 says unknown fields 'e.g. shot_track, shots_locked, clip shot_type' are ignored via extra=ignore. So this is a read-side task, the same shape as #1026: the write side is built and the consumer doesn't look at it. WHAT TO BUILD * magicam's alchemy adapter consumes shot_track: one MagiCam per SHOT, with each beat inside that shot becoming a keyed frame/plane on it, instead of one camera per block. * The beat board editor surfaces the grouping so the artist can say 'these six beats are one camera' - i.e. edit the shot boundaries and set shots_locked when they do. There is currently no camera/shot distinction visible on the board at all, which is why it defaults to one-per-beat. NAMING - DECIDE BEFORE BUILDING, THE WORD IS TAKEN TWICE alc/models/framing.py already defines as the shot VOCABULARY - a composition of Framing + ShotRole + CameraAngle + CameraMovement, i.e. HOW a shot is described. alc/models/edit/models.py defines a different - a segment on the shots track, i.e. WHICH beats a shot spans. Two models, one word, both live. State which one the board's grouping means (it is the second) and how the two relate - because the first is the natural payload OF the second: framing, angle and lens are properties of the CAMERA, not of each drawing under it. WORTH NOTING: framing.Shot is populated NOWHERE today - is None on all 16 blocks of the live theaxe board. A camera-level grouping is the natural place to hang it, and hanging it per-drawing was probably always the wrong altitude. DONE WHEN: a run of beats that share a setup exports as ONE MagiCam with the beats as keyed frames; the artist can group and re-group beats into cameras on the board and the grouping survives a rebuild (shots_locked); and a board of 14 beats that is really 8 setups produces 8 cameras, not 14. OUT OF SCOPE: camera placement (Tom: placement is not the bottleneck - 10 cameras in 3-4 minutes); the multiplane depth workflow itself.

Previs exports ONE MagiCam per beat. On the theaxe board that gave 14 cameras where roughly 6 boards are one continuous setup — successive drawings of the same shot, not 6 shots. The result over-complicates the scene, and the artist has to reconcile 6 cameras that should have been one. MAGICAM ALREADY DOES THIS — it was built for TVPaint that way. magicam/blender/build.py loops the clip's LAYERS into image_plane_01..10 under a SINGLE camera, and set_key_frames() keys the image sequence over time. One camera, many drawings, keyed. The capability is not the gap. THE GROUPING ALREADY EXISTS TOO — AND NOTHING READS IT alc/models/edit/models.py:1283 declares a `shot_track: Track` field alongside `shots_locked: bool`, and models.py:89 defines a `Shot` clip — "a shot segment on the shots track" — carrying `shot_type` and its own `clip_range`. ScriptScene._build_shot_track() (script.py:512) already SEEDS it: a run of consecutive action blocks becomes ONE shot, each dialogue block its own shot, derived from the effective voice track so it stays frame-aligned with what the artist sees. `shots_locked` already means a human committed manual cuts, and those win over the derived ones (script.py:586-596 and 714-715). So "the artist regrouped these beats and it must survive a rebuild" is already modelled. And magicam explicitly THROWS IT AWAY: magicam/alchemy/models.py:118 documents that unknown fields — naming `shot_track`, `shots_locked` and clip `shot_type` — are ignored via the model's extra="ignore". So this is a READ-SIDE task, the same shape as #1026: the write side is built, and the consumer does not look at it. WHAT TO BUILD * magicam's alchemy adapter consumes the shot track: one MagiCam per SHOT, with each beat inside that shot becoming a keyed frame/plane on it, instead of one camera per block. * The beat board editor surfaces the grouping, so the artist can say "these six beats are one camera" — edit the shot boundaries and set shots_locked when they do. There is no camera/shot distinction visible on the board at all today, which is why it defaults to one-per-beat. NAMING — DECIDE BEFORE BUILDING, BECAUSE THE WORD IS TAKEN TWICE alc/models/framing.py defines a class named `Shot` meaning the shot VOCABULARY: a composition of Framing + ShotRole + CameraAngle + CameraMovement — HOW a shot is described. alc/models/edit/models.py defines a DIFFERENT class also named `Shot`: a segment on the shots track — WHICH beats a shot spans. Two models, one word, both live in the codebase right now. State which one the board's grouping means (it is the second) and how the two relate — because the first is the natural payload OF the second: framing, angle and lens are properties of the CAMERA, not of each drawing under it. WORTH KNOWING: the framing vocabulary is populated NOWHERE today — the per-block `shot` field is None on all 16 blocks of the live theaxe board. A camera-level grouping is the natural place to hang it, and hanging it per-drawing was probably always the wrong altitude. DONE WHEN: a run of beats sharing a setup exports as ONE MagiCam with those beats as keyed frames; the artist can group and regroup beats into cameras on the board and the grouping survives a rebuild; and a 14-beat board that is really 8 setups produces 8 cameras, not 14. OUT OF SCOPE: camera PLACEMENT (Tom, measured: placement is not the bottleneck — 10 cameras in 3-4 minutes); the multiplane depth workflow itself.

The beat board's STYLE rail renders the Style Prompt textarea only when style_mode == 'prompt' (transcript_style.html:43); in Reference and Storyboard mode the spine is kept but hidden behind a hidden input. That was right when the spine ONLY fed prompt-mode image generation. It stopped being right with the style-frame column (#1748): a style frame is the FINISHED LOOK by definition, so it injects the resolved spine whatever mode the video is in - meaning a video in Storyboard mode now has a spine that drives real output and no field to see or set it. Tom hit this directly on loj/theaxe (Storyboard mode): changing things in the rail did not move the style-frame prompt, because the only control that would have was not on screen. WANTED: the video's effective spine is always VISIBLE in the rail - editable in every mode, or at minimum shown read-only with the inherited project value beside it and a note saying which passes read it. Tom: 'the video's style isn't visible - we're going to have to make that clearer later because this is a feature we want - video specific style.'

Opening a canonical coordinate URL WITHOUT its query tail — e.g. /c/cgl/project/loj/transcript/at/videos/theaxe/SEQ/scr — leaves the PathObject with no user and no version. The page still renders, but degraded and silently: the phase-header context logs 'RouteEngine could not resolve: .../scr/default.msd' and is dropped, and the Previs Prep band never draws, so the whole previs control the band gates is absent. Adding ?u=tom&v=000.000 makes the same page render correctly. Either the /at/ route should resolve the missing tokens to defaults (the logged-in user, the latest version) the way _editor_task does for the query-context path, or a coordinate missing user/version should be an explicit redirect to the resolved one — but a half-resolved coordinate should not quietly render a page with features missing.

A shot's style_frame folder can hold both style_frame.{fs}_styled.mp4 and style_frame.{fs}_tween.mp4 — two different Seedance results under two different stems. The scene timeline's scan (alc/services/media/prv_media.py: ensure_styled_offsets and the STYLE FRM/video cell builder) globs '*_styled.hero.mp4' FIRST and falls back to the square, so it silently prefers the styled clip whatever the artist last asked for. Live example today: loj/theaxe 010_010_0120_MagiCam holds both, and the beat board's v0017 points at style_frame.0395_tween.hero.mp4 while the downstream scan reads the styled one. Board and timeline disagree about what this shot is. #3206 fixed this going FORWARD — a take made live retires the other stem into the takes/ archive, so only one canonical clip exists per shot from the next pass or the first 'Make live' onward. What is left is the EXISTING shots on disk: nothing reconciles a shot that already holds both until somebody touches it. Wanted: a one-off reconcile that walks a render version, and for each shot holding both stems, adopts both into the take archive (ShotTakes.adopt_canonical) and retires whichever stem the BEAT is not pointing at — i.e. makes the artist's choice the live one. Report what it changed rather than doing it silently.

tests/test_visual_lane_overlap.py::test_transcript_mode_row_gets_no_visual asserts a transcript-mode row is born WITHOUT a visual. It fails on main (verified by stashing all local work): TranscriptEdit.add_row now runs _ensure_row_visual for every row, because the beat board made row:visual 1:1. Decide which is true — either the beat-board invariant is universal and the test should assert the row DOES get its one visual, or transcript mode is meant to stay visual-less and add_row should skip _ensure_row_visual there. Then fix whichever side is wrong so the suite is green.

The Premiere panel now carries the app header's Request field (#3276), and the filing route it uses is generic: POST /c/{company}/request/api (app/tools/kanban/request.py) takes text/kind plus software, window, company, project, alc_path, page, view_route, and answers with the card number and its /alc_do_ticket command. alc/plugins/premiere/bridge/server.py POST /request is the reference implementation — it grounds a PathObject from the open project, names software='premiere' so plugin_facets() routes the card to the plugin's own area, and points the evidence camera at the Premiere WINDOW because headless Chrome cannot photograph a DCC. Do the same for the Blender dashboard (bridge on :9876) and the Substance Painter panel (:20260): one field on the panel header row, everything else filled in from the live session.

WorkItem.resolve_candidate_files() ranks real files (a Premiere request scoped to Plugin - premiere - edt resolved 24 files, with the three marker js ops correctly on top), but the selection filter at the end of that method only marks a candidate selected when score >= 8.0, or when a direct UI-keyword/template hit set the reason to html_ui / renders_template / explicit_note / cookbook_context. A request filed from a DCC panel has no UI keywords, so nothing clears the bar and _candidate_files_block() returns '' - the agent gets the area scope line but never the ranked file list underneath it. Either select the top N when there are no direct hits, or lower the threshold for area_default candidates.

Quick entry is one field, and the one thing it cannot express is the single strongest signal the ticket enricher has: the on-screen LABEL of the thing being talked about. WorkItem.resolve_candidate_files() scores a file far higher when a ui_keyword appears in its templates/markup (reason html_ui / renders_template), and those direct hits are also what flips candidates to selected — so a request filed with no keywords ranks its area's files but surfaces none of them. Add an inline convention to the request text, parsed at capture time. Proposed: a '#uikey ' marker consuming a comma-separated list to end of line — the marker sync button should run on open #uikey Sync markers, Task type — stripped out of the title before the card is created and passed through as ui_keywords. Worth a look at the alternatives before committing: inline [Bracketed Labels] anywhere in the sentence (no trailing-position rule, reads naturally, but collides with prose), or ackticked labels (familiar from markdown, same collision risk). Pick one and teach it in the field's placeholder and tooltip. Parse it in file_request() in app/tools/kanban/request.py — that is the single composition every capture surface already goes through, so the web header pill and every DCC panel (Premiere today, Blender/Substance under #3295) get it at once, with no per-surface UI. add_item() already takes ui_keywords; nothing downstream needs to change.

On the Ontology page (Pipeline tab), let a user act on a lint finding in place instead of only seeing it. Add inline edit affordances on each page/tool row to correct a bad label, route, or workspace assignment — mirroring how the Features/Activity Report tool lets you retype a file's classification. Edits write to app/navigation.py's registries (TOOL_PATHS / SIDEBAR_NAV / SECTIONS) or a companion override store, then re-run lint_ontology() so the finding clears live. Turns the monitoring surface from read-only into a fix surface.

The Ontology page's identical-render lint (average-hash comparison of captured page thumbnails) only covers pages that have been captured, so today it's near-empty until someone clicks Capture on each row. Add a background sweep that captures thumbnails for all registered pages/tools without a manual per-row click — self-retriggering like the Features tool's cache-step indexer, honoring the screengrab service's per-page cost, and best-effort (a failed page never breaks the batch). Result: the look-alike-render flags have full coverage automatically, so Script-vs-Transcript-style pages that render nearly identically are caught without manual effort.

The Ontology page currently monitors only the UI->pages taxonomy (navigable tools/routes from app/navigation.py) and links out to the Activity Report for the code-side areas/features. Fold the code-side taxonomy in so 'areas & features' live on the same monitoring board: join the FeatureRegistry (alc/models/feature.py — areas + derived features) alongside the pages lens, and extend lint to cross-check them (e.g. an Area with no owning page, a page whose owning workspace has no matching code area, orphaned features). Keep it a pure reducer; reuse alc/services/ontology.py. Goal: one ontology surface covering both what the app OFFERS (pages) and what it IS (features), not two separate tools.

Generate a character model from the identified t-pose file in the design task.

Ensure the required views for this category are met. alc\plugins\alchemy\tasks\dsn\tags.py contains the REQUIRED_TAGS dict we can pull from.

Ensure we create a blend file for the design camera based on the data in the json file we've created in our breakdown and scale work. the camera should include the ground plane a blender camera with our camer's settings, and an image plane at 30% attached to the camera to for a complete reference

Create a Headshot the same way we do on the character dashbord.

Find all published Rigs connected to this scene and import them into Unreal - we'll essentially be running the unrea / rig / build recipe on each one.

Ensure that there's a [SceneName]_SEQ_lvl witha ground plane and a sky at a minimum

Opens up the Render Manager so you can submit renders from the UI.

Launches the HDRI tool

Launches the Camera Caddy

INT_SEQ_lvl — parent: empty container, streams the rest INT_SEQ_lay_lvl lay ground, env, set INT_SEQ_prv_lvl prv previs blocking/proxies INT_SEQ_cam_lvl cam the mCams + plates INT_SEQ_lgt_lvl lgt HDRI sky, lights

Import the GLB file from the design publish

Setup the HDRI for the scene, start with a basic sunny day like: mondarrain_3_thumb, put it in the lighting sublevel, ensure that level is in the location level (it already should be)

Ensure that a project exists for the location this scene or video is connected to.

Import the environment fbx if it's available. Import and attach the textures if they are available as well.

Motion-clip sequencing/editing for characters in UE, using UE SEQUENCER as the native NLE (it's already excellent — do NOT port Alchemy's NLE UI), fed by the Alchemy motion library. This is the mtn.create.apply_sequence(Timeline) leg for UE — the contract already anticipates it ('sequence realization building native NLA/Time-Editor/Sequencer', smart_task/mtn.py). Depends on #266 (retarget_clip primitive + calisthenics). RECOMMENDED APPROACH — leverage native, sync the data: (1) apply_sequence(Timeline) for UE: given an Alchemy Timeline (source-of-truth NLE model — ordered MotionClips per character with clip_start_frame/clip_duration/source_in-out/blends, see alc/models/motion.py), build/populate a Level Sequence: one skeletal-animation track per character, each clip a section at its frame, retargeted via retarget_clip (#266). Sequencer's native trim/blend handles crossfades. Mirror blender mtn create.py apply_sequence + set_track + bake_track. (2) Motion library access in UE: reach the library from the connected session — pre-land library clips as AnimSequences at library coordinates + retarget-on-demand (MVP: Sequencer asset browser); a RigCaddy-style motion picker (see rig_caddy/timeline.py, ui.py) later. Reuse MotionLibrary catalog + previews. (3) Blocking bridge: rig-task marks already attach a clip (rig.edit.set_mark_motion); apply_sequence lays those clips at mark frames so director's blocking populates Sequencer. (4) Round-trip / source of truth: Alchemy Timeline is authoritative (1:1 NLE). Timeline->Sequencer build first (previs); an mtn.query read-back of Sequencer sections -> Timeline keeps the 1:1 later. OPEN DECISIONS (triage): authoritative surface (recommend Timeline-drives-build, Sequencer read-back later, NOT Sequencer-as-master); library-in-UE (pre-land AnimSequences + Sequencer browser for MVP vs in-session picker); retarget caching (cache baked AnimSequences at coordinates, idempotent like image_to_mesh — retarget-per-character-clip is expensive). REFERENCE: smart_task/mtn.py (apply_sequence/set_clip contract), blender/tasks/mtn/create.py (apply_sequence/set_track/bake_track/calisthenics_turntable to mirror), alc/models/motion.py (MotionClip/Timeline/MotionLibrary), rig_caddy/timeline.py (app-side NLE), rig task marks. Dependency: motion library needs UE-accessible clips (same as #266).

Two cosmetics from #234: (1) 'No module named numpy' fires in an optional HDRI-light path during build_turntable inside headless UE (caught; the step passes; we don't add lights). Either guard the numpy import so it never logs, or install numpy carefully (UE bundles its own — risk of version clash, hence excluded from setup requirements). (2) The Plugin loader logs 'unreal is missing query/create module' because Plugin.model_post_init expects flat alc.plugins.unreal.{create,query} modules, but the etymology puts ops under tasks/{task}/{verb}. Make the loader not warn for a DCC that uses the tasks layout (or provide thin shims).

test_parity.py reports 3 pre-existing contract-drift failures (unrelated to any one feature): (1) unreal mdl/create.py import_file adds game_folder/asset_name kwonly args beyond the ModelCreate contract signature — either lift them into the contract or drop them from the op; (2) unreal prv/query.py is missing contract ops get_shot_cameras, list_sequences (PrevisQuery); (3) maya prv/query.py is missing the same two PrevisQuery ops. Reconcile concrete<->contract so contract-⊆-concrete holds with exact signatures.

Several board items carry an area_id that FeatureRegistry has no entry for: svc-unreal, alc-services, alc-plugins, plugin-premiere-amc, plugin-unreal-cam, plugin-alchemy-camera-caddy. Because the card renders its area via area_names.get(area_id), those cards show NO area at all, and anything driven by the taxonomy (candidate-file resolution via path_prefixes, the new sprint planner's code-path grouping) degrades for them. Decide and implement one of: (a) re-register the missing areas from their ids/paths so the taxonomy claims them again, or (b) migrate the items onto the areas that superseded them. Then add a guard so an item can't be saved with an area_id absent from the registry.

Alchemy's setup() bootstraps now install third-party software onto machines Alchemy does not own — mGear onto Maya, and with #3860 the Khronos glTF plugin onto 3ds Max. On a client or farm machine that is redistribution, and each license has terms that travel with it. Do three things. (1) Make the installers deploy the upstream LICENSE and NOTICE next to the binaries: the Khronos release zip ships NEITHER, so gltf.py must fetch them from the repo rather than assume the zip is self-describing. (2) Write down the pinning policy the pinned-release constants already imply — a version bump is a deliberate, tested change, not a float, and the ticket that bumps it says what was verified. (3) Add a short section to the docs listing every third-party dependency Alchemy installs on a user's behalf, its license, and where it lands on disk. Done when: a fresh install carries its licenses, and one page answers 'what does Alchemy put on my machine and under what terms'.

Two non-fatal wrinkles from the #234 headless run: (1) UnrealEditor-Cmd segfaults on SHUTDOWN after the recipe completes (rc 3221225477 / 0xC0000005). The work + the 'ALC HEADLESS: recipe complete' marker land first, and run_recipe_headless keys success off the marker not rc — but a farm job may treat rc!=0 as failure, so make the exit clean (or make the marker the authoritative success signal for Deadline). (2) A MovieScene section-range ensure fires during build_turntable (Ensure: SectionRange upper bound >= NewStartFrame, MovieSceneSection.cpp:270) — set the transform/camera-cut section ranges so the ensure doesn't trip.

Extend BP_MagiCam (#258) and cam.edit (#260) BEYOND the Blender MagiCam 1:1 set - these are wanted here (supersedes the 'do not add' note in #258). Group by mechanism: (A) NATIVE CineCamera, near-free - focus distance (manual + tracking), aperture/f-stop, depth-of-field enable. Expose as set_focus(distance)/set_aperture(fstop)/set_dof(bool) + Caddy controls. (B) ROTATION CHANNELS on the rig components - roll (camera Z-rot) and pan (yaw), add as controls alongside Tilt: select_control gains 'roll'/'pan', or dedicated set_roll/set_pan. (C) PROCEDURAL - camera shake via a UE Camera Shake source / handheld noise component on the rig, with an intensity control (the meatier bit; previs-good-enough). All keyable via key_camera and surfaced in the Camera Caddy UMG (#261). NOTE (follow-up, not now): once proven here, back-port these same controls into the Blender MagiCam rig (magicam-blender caddy) so the two stay at parity.

open_project() currently launches with Unreal.detect() (the newest local install, e.g. 5.7). Opening a project authored in an older engine (forest.uproject is 5.6) makes UE show a version-select / conversion prompt. Read the target version from the .uproject's EngineAssociation (or let the user pick) and launch the matching UnrealEditor when installed, falling back to detect() with a clear note. Surface the chosen version in the connection header (it already shows 'UE <ver>').

alc/plugins/unreal/setup/init_unreal.py hardcodes ALC_ROOT (C:/Users/tmiko/PycharmProjects/alchemy) and CB_ROOT (E:/Alchemy/cgl/config/cgl-cookbook). This is UE's startup hook that puts alc + the version-scoped site-packages + cookbook on sys.path. Derive these instead: ALC_ROOT from the file location (walk up from __file__ to the repo root), CB_ROOT from an env var (ALC_COOKBOOK_ROOT, exported by configure_unreal_python_env / the launch) or a small sidecar the project-env writer drops next to the .uproject. Blocks running Alchemy-in-UE on any machine but Tom's.

alc.plugins.unreal.setup.Unreal has a hard-pinned 'version' class default (now '5.8'). detect() already picks the latest installed UE under Epic Games, but any code path that constructs Unreal() directly (not via detect()) uses the pinned default, which goes stale on every engine upgrade — as happened going 5.6 -> 5.8 (deps installed into the wrong version-scoped site-packages until re-pinned). Make the default resolve to the detected install so an engine upgrade needs no code edit: e.g. compute version lazily from get_local_versions()[-1] (or the running editor path like init_unreal._ue_version does), keeping an explicit override for pinning.

On the versions view file zones, the right-click context menu now works on file rows and folder rows (#1594). The third row kind -- an image SEQUENCE row (kind == 'sequence' in app/templates/partials/version/_browse_row.html, rendered with the 'seq' badge and film icon) -- still has no oncontextmenu handler, so right-clicking a sequence does nothing. A sequence is not a single path (it is a frame pattern like foo.####.exr plus a directory), so it needs its own menu shape rather than reusing the file one: likely 'copy folder path', 'view in Explorer', and possibly delete-the-whole-sequence. Decide which actions make sense before wiring it.

The back arrow in the version view header should carry hx-push-url so clicking it writes the asset-grid URL to the address bar, matching the task pills (which do push, via the server's HX-Push-Url response header).

When a recipe/preflight step errors, the Alchemy agent-chat surfaces only a one-line message (e.g. 'Hit an error during Render Turntable: module unreal has no attribute EditorAssetLibrary'), composed in cli_runner.run_preflights. Carry the FULL Python traceback into the event/bug payload and render it in the chat (collapsible if long) so debugging is self-sufficient without digging into Deadline/worker STDOUT. PreflightCheck.fail_check/update already has the feedback; capture traceback.format_exc() at the except site in cli_runner and include it in the emitted event + log_bug traceback.

we need to come up with a way to test the places we click on within the app - especially when browsing side links and versions - to ensure we're updating the path_object / footer when navigating the app. Probably derive some test for that so that we don't have inaccurate or stale links and maybe even come up with a more foolproof system for it in general.

this is the version view - it's a known area - we have a system for tracking / predicting which phase we're currently on - we need to revis it as it's not terribly useful right now. as a side note we need an App * Version View in the taxonomy

Let the user reorder Tracker columns by dragging column headers, and persist the order per project+tab (localStorage, like the existing AlcTracker column-hide prefs). On render, re-apply the saved order by reordering both the header cells and every body cell keyed by data-col. Fixed columns (name, rollup Status, spacer, Priority) stay pinned; only the movable middle columns (task-status + info fields) reorder. Must survive HTMX swaps (re-apply order after each swap, same as AlcTracker.apply). Consider a small drag handle and drop indicator on the th.

The unreal Scene gateway currently runs recipes against the CONNECTED editor over the bridge (run_preflights in the app venv). Add a true headless mode: launch UnrealEditor-Cmd on the world's .uproject (already Alchemy-configured by configure_unreal_python_env) with a python bootstrap that runs run_preflights(recipe, scene_file) and exits — the analog of blender's plugin.setup.run_recipe. Wire it so Scene._run_recipe(headless=True) spawns it when no editor is connected (or always, per a flag).

unreal/build/mdl/mdl.json step 2 (BuildModelTurntable) is still old cglumberjack PreflightCheck/cgl.* code, so Run All imports jack (step 1, refactored) then fails on the turntable. Refactor it to a new alc.cookbook.preflight.PreflightCheck subclass using the unreal common/ldv turntable ops (dispatched via the executor to the connected UE), mirroring the ImportLatestModel refactor done in #234.

When the Deadline toggle is on, Run All returns only a job_id (batched) or a RunResult (chained) and the new Phase Details console prints nothing, so a farm submission looks identical to nothing happening. The console should log the submitted job name/id, the mode (batched/chained), and any submission error, the same way local runs now log their step messages.

i want a button that will allow me to draw a box to collect a screen grab and attach it to the work item / kanban card. this will allow users to be very specific with images in their requests. We can put this button within the Reference Files Section.

Make the multi-worker path of alc_sprint end in a single, testable integration branch instead of N loose worker branches. Standard flow: (1) fan out one worker per item/cluster in isolated worktrees (as today); (2) each worker COMMITS its work to its branch (workers currently leave changes uncommitted in the worktree - the orchestrator had to commit them by hand this session); (3) orchestrator creates sprint/<name>-<YYYYMMDD> off the CLEAN COMMITTED main ref (never the shared working tree, which may hold another session's uncommitted work) in its own dedicated worktree; (4) merge all worker branches into it (--no-ff), resolve conflicts, run tests + an in-app smoke on the MERGED tree (a clean auto-merge is not a correct merge); (5) commit the sprint branch and STOP - hand it to the user for testing. On approval: push + open PR. Anything found in testing is fixed on the sprint branch, not scattered. OPEN DESIGN QUESTION to settle: board state model - do items flip to done at per-agent verification (as now), or to an intermediate in-review/on-branch state that only becomes done on sprint-branch approval? The user leaned toward the latter (wait-for-testing, address-on-branch). Consider a sprint_cli helper (e.g. 'integrate') that automates worktree creation + ordered merges + reports conflicts, so the orchestrator does not hand-roll git each time. Ties to alc_do_ticket wrap-up conventions.

DEFAULT_STORYBOARD_STYLE in app/tools/script/script_viewer.py:789 pins the scene-wide drawing hand to a literal absolute path (E:\Alchemy\_storyboard_test\tani_board.png) that only exists on Tom's box. Move the style key somewhere addressable — a published design/style asset resolved through PathObject, or a project Style setting — so the Render Storyboards pass draws with the same hand on any machine (and on the farm) instead of silently falling back to no style reference.

Ensure that all image files, glb files, and any mov files are copied to the render directory of this version's pathObject so that they will show up as review media, as well as be ready for publish.

if we're dealing with a chr (pathObject parent) we need to know that a Character type is set - humanoid for example, quadraped, bird, etc...

Two editor pages look nearly identical but are different tools with different core functions: the transcript tool renders a script-editor face (its page header reads 'Create Script') at /transcript/.../scr, while the separate 'Script' tool renders the script reader at /.../read. This ambiguity mis-routed sprint tickets (agents built left-panel + playhead features against the Script tool when the user meant the Transcript editor). Two parts: (1) Disambiguate the tool taxonomy/labels so it's obvious which tool/page you're on and what each owns (rename/relabel so 'Script' vs 'Transcript' is honest, or merge if they've converged). (2) In the taxonomy/tool-picker (and ideally the feature-ontology view), attach a per-page visual confirmation - a still captured via the existing screengrab service - so each registered page carries a thumbnail of what it actually renders. Early-stage, this keeps pages honest and surfaces ontology litter (duplicate/near-duplicate pages, stale routes).

A location in Alchemy IS a whole Unreal project, not a level inside one. Locations live as {location}.uproject under the Perforce root - C:/alc/p4v/{company}/{project}/PERFORCE/{location} - and every sequence shot at that location is built in that project. Any sequence at Jack's homestead, now or in three months, is in the "homestead" project. The previs build assumes that project already exists. For a location that has never been to Unreal, it does not, and there is nothing to build into. BOTH LEVELS OF THIS ARE REAL - DO NOT COLLAPSE THEM * the LEVEL for the sequence: already handled, by the existing EnsureSequenceLevels step (order 0 of cookbook/unreal/build/prv/prv.json). Untouched by this ticket. * the PROJECT for the location: missing, and this ticket. It sits one level up, and BEFORE EnsureSequenceLevels - you cannot ensure a level inside a project that does not exist. THE CREATION ALREADY EXISTS - REUSE IT, DO NOT RE-SCAFFOLD The Locations page's "+ New Location" already does exactly this work: app/routes/unreal.py::unreal_create_location calls create_location(perforce_root, company_id, project_id, world), which writes a minimal content-only {world}.uproject plus Config/DefaultEngine.ini with the Alchemy plugins enabled (via configure_unreal_python_env, the same call open_project runs), and lets the engine hydrate Binaries/Intermediate/Saved on first launch. So this step is a caller, not new scaffolding. Take ue_version and connect_session deliberately rather than by default - a headless previs build has different needs from a person clicking New Location. WHERE IT RUNS. Note it does not need Unreal: it writes two files on disk. That is what lets it be the FIRST step and still work headless - the thing it creates is the thing everything after it needs UE for. Order it before EnsureSequenceLevels and make sure the connection/open that follows targets the project it just made. NAMING IS THE CONTRACT. Establish explicitly how an Alchemy location maps to the project name (homestead -> homestead.uproject) and use one rule, so a location created by this step and one created by hand from the Locations page are the same project rather than two that differ by a case or a slug. IDEMPOTENT, like every other link in these chains: creating it twice is harmless, an existing project is never replaced or re-scaffolded, and its contents are never disturbed. The rest of the prep chain already reads this way (Process Designs sweeps and fires only what is missing). SAY WHICH IT DID. Created-vs-found is exactly the kind of thing that is invisible until someone wonders why their project is empty - log it, and surface it in whatever the previs build reports back. It should also show up on the Locations page afterwards like any other location. DONE WHEN: building previs in Unreal for a location with no UE project creates one under the Perforce root and proceeds; the new project appears on the Locations page and opens in Unreal; building again finds it and proceeds without touching it; EnsureSequenceLevels still owns the sequence's level; and the step reports which of created-or-found happened.

Add an ImportDesignGlb step to the Unreal previs build that brings in the published design GLB for EVERY asset on the board - characters, props, dressing and environments - not just the environment. WHY IT IS WORTH ITS OWN STEP Unreal does not care about geo count. The reason Blender builds a proxy at all - viewport weight, clean topology for lookdev - simply does not apply, so the heaviest thing we publish is also the cheapest thing to hand Unreal. And the design GLB exists EARLIEST: the dsn chain publishes it before any model or rig follows. That means a previs can stand up with something visible for every asset on a board whose chain is only part-way done, instead of waiting for the whole design -> model -> rig chain to finish for every last prop. That is the real value: previs is for judging cameras and timing, and a stand-in at the right size in the right place does that job. An empty level does not. DECIDE AND STATE: always, or fallback? Two readings, and they behave differently: * ALWAYS - import the design GLB for every asset regardless of what else exists. Simple, and the previs always has everything. * FALLBACK - import it only where no model/rig has been imported by ImportConnectedRigs / ImportEnvironmentModel, so a rigged character is not shadowed by a static copy of itself. The second is almost certainly what is wanted for characters (a rig and a static duplicate in the same spot is a mess), and the first is fine for dressing and props. Pick per asset kind if that is the honest answer, and write down the rule. ORDERING. It has to run after the project and level exist (#1009, EnsureSequenceLevels) and its relationship to ImportConnectedRigs / ImportEnvironmentModel depends on the decision above - fallback means it runs after them and fills gaps; always means order barely matters. Say which and why in the step's docstring, because the next person will ask. PRECEDENT TO REUSE: cookbook/blender/build/mdl/ImportDesignGlb.py already exists as the Blender counterpart, and its docstring is explicit that the GLB lands in the DSN collection and is NOT promoted to the mdl hierarchy - it stays the hero. Take the naming and the meaning of "design glb" (the published dsn output) from there rather than inventing a second vocabulary for the same file. IDEMPOTENT, like every link in these chains: importing twice must not duplicate actors, and a re-run must not disturb what is already placed. PLACEMENT: assets need to land somewhere sane - at origin is not good enough for judging a camera. Say what placement this step gives them, even if the first pass is "wherever the design says" or "at the location's origin, to be moved by hand". DONE WHEN: a previs build brings in a visible stand-in for every asset the board declares; the always-vs-fallback rule is implemented and written down; re-running does not duplicate anything; and a board whose props only have designs still produces a previs with those props in it.

27 cookbook step files import 'from alc.plugins.preflight.preflight_check import PreflightCheck'. That module does not exist - alchemy has no alc/plugins/ package at all; the class lives at alc.cookbook.preflight.preflight_check, which is what every WORKING step imports (see blender/publish/rig/CleanScene.py). These steps therefore raise ModuleNotFoundError on line 1: the runner cannot load them at all, so any recipe containing one dies at that step in a live DCC. THE FIX for those 27 is mechanical - swap the import path. The affected files, from tests/known_issues.py::STALE_ALC_IMPORTS: blender/build/srb/{AddEnv,CreateWorldCollection,EnableStoredViews,ImportBoardsAsMulticam,RefreshImages,SetFps}.py; blender/build/svz/{AddCharacters,AddEnv,AddStoryboards,EnableStoredViews,SetFps,SetupSceneCollections}.py; blender/pre_render/wkb/{Render,SetPath,ShowInExplorer}.py; blender/publish/svz/{CreateLayoutMsd,ExportCamears,ExportGeometry,ExportStoryPoses,Publish}.py; blender/publish/wkb/{ExportCameras,ExportGeometry,ExportStoryPoses,Publish}.py; blender/tasks/{srb,svz,tex}/task.py. SEPARATELY, 4 files do not even parse as Python and need real repair or deletion, not an import swap (tests/known_issues.py::UNPARSEABLE_STEP_FILES): blender/refresh/srb/CheckForNewLayers.py and blender/refresh/srb/UpdateImagePlaneVersions.py both literally declare 'class Check For New Layers(PreflightCheck):' with spaces in the class name; maya/publish/shd/ExportShader.py uses a Python-2 print statement; unreal/build/prv/EnsureSequenceLevels.py is not valid UTF-8. FIRST DECIDE WHETHER THESE ARE DEAD CODE. srb (storyboard), svz (story viz) and wkb (workbook) may simply be abandoned - if a task is no longer run, DELETE the steps and their recipes rather than repairing imports nobody calls. Ask before deleting. DONE MEANS: the corresponding entries are removed from tests/known_issues.py and the cookbook suite still passes - the ledger asserts in both directions, so a fixed entry left behind fails the build just as a new breakage does. Note blender/publish/svz/ExportCamears.py is misspelled in the repo itself; renaming it is a separate decision because the recipe JSON references that spelling.

An explicit per-beat "has dialogue" flag that controls whether the lipsync portion of the prompt is INSERTED. It gates composition; it does not change a word of what gets composed. Today the lipsync suffix is appended implicitly, based on whether a voice take auto-resolves for the shot (resolve_shot_voice, via styled_video in alc/services/ai/shot_finish.py:242-254). Nothing states the intent and nothing can override it. What it should do: - A per-beat flag on the visual/beat, surfaced on the video payload modal next to the other per-submission controls, reading as "has dialogue" / lip-sync this shot. - Flag ON -> the lipsync aspect of the prompt is inserted, EXACTLY as it composes today. - Flag OFF -> it is not inserted, and no dialogue audio is sent. - DEFAULT must reproduce today's behaviour: derive the initial value from whatever the current auto-resolution decides, so an untouched beat submits precisely what it submits now. This is an override, not a new decision. NON-NEGOTIABLE: the composed prompt for a dialogue beat with the flag ON must be BYTE-IDENTICAL to what the pre-change code produces. Lock it with a test. The dialogue path is production-proven with weeks of tuning behind it and is not being redesigned here — see the guard card #2507. This ticket adds a switch in front of it and nothing else. Why it is needed and not speculative: 1. VO / narration. A beat carrying narration over a shot where nobody is speaking on camera currently auto-resolves the voice and instructs the model to lip-sync it — so a character mouths narration. The flag is the off-switch for that, and there is no other one. 2. The mode dial (#2452) already needs this distinction. "prompt" mode and "tween" mode (#2493) cannot lip-sync — tween clips have no audio at all. Prompt assembly has to know whether the lipsync aspect applies, and an explicit flag says it rather than inferring it from a chain of resolution calls.

Steps marked required:false are not gated by prior-step failures — they run anyway and can do real, polluting work in a broken build. Observed twice on 2026-08-04 with unreal/build/rig: CreateRigFromDesignGlb crashed, ImportGlbRig and AutoRig were correctly 'Skipping (prior failure)', but BuildRigTurntable (required:false) RAN, imported genMan plus six motion clips into the project as retarget source, and only then failed with "no asset at '/Game/assets/chr/zhou/rig/default/chr_zhou_rig'". The user had to hand-clear the polluted content folder before each retry. 'required: false' should mean the recipe can pass without this step, not that the step is immune to gating. Decide and implement the intended semantics: a non-required step should still be skipped once an upstream step in the same recipe has failed.

Unreal's python environment (E:/Alchemy/cgl/config/plugins/unreal58/site-packages) is a hand-curated ~38-package subset, while the app venv carries ~400 more. Any alc code path that reaches a dependency outside those 38 dies inside UE with an ImportError that looks like a bug in whatever step happened to touch it. Hit twice on 2026-08-04 in a rig build: 'No module named xmltodict', then 'No module named pandas' once the first was installed — both pulled in via alc/models/script/ (the asset manifests live under the screenplay module). Those two specific imports were made lazy (see the fix/ue-rig-env-and-hdri PR), but the structural gap remains and will recur with a different package. Decide the intended contract and implement it: either the UE env is generated from the app's dependency set rather than curated by hand, or alc guarantees an import-clean core that never reaches heavy optional deps, with a test that asserts it.

run_cookbook(software='unreal') trampolines the WHOLE recipe into a headless UnrealEditor-Cmd, including steps that touch no Unreal API. Two concrete cases from 2026-08-04: (1) unreal/publish/rig is pure file-copy plus MSD commit, yet each publish pays a ~20s engine boot and takes the project lock, so it cannot run while an artist has the project open; (2) CreateRigFromDesignGlb is an app-side Meshy HTTP round-trip whose own docstring says 'app-side (the Meshy round-trip needs requests + routing context UE doesn't have)' — running it inside UE is why a missing pandas in the curated UE env could kill it, and it holds the engine open for minutes waiting on a cloud call. Let a recipe or step declare that it runs app-side, so only the steps that genuinely need the editor pay for one. Tom's framing: do the Meshy glb before even opening UE — UE should open only when there is something to import.

#3059 publishes a committed expression frame with a one-layer manifest beside it (alc/services/ai/expression_harvest.py::_write_base_layer, via alc.services.media.layer_doc), marking the harvested frame as the `generated` base layer so a paint-over lands ON TOP of it and "what did the machine make" stays answerable forever. The write side is unit-tested (tests/test_expression_slots.py::test_the_generated_frame_is_kept_as_its_own_base_layer). What is NOT verified end to end is the ROUND TRIP through the image editor: 1. click a filled expression slot on a character's dsn version view (it calls launchInternalEditor on the committed PNG) 2. confirm /load-layers reads the manifest and shows ONE layer named "<Label> (generated)" rather than treating the PNG as a flat image 3. paint on a new layer and save 4. confirm /save-layers keeps the generated base as its own bottom layer with generated=true and entity_id=<character> intact, and does not flatten it into the painted result Step 4 is the one that matters: the whole point of not flattening on publish is that a later correction never starts from the corrected image. app/tools/image_editor/image_editor.py rebuilds layer entries from what /load-layers handed the client, so the flag SHOULD survive - but nobody has run it on a dsn file rather than a storyboard board.

In the image editor's Layers panel, Delete Layer does NOTHING when the selected layer is the bottom of the stack — no deletion, no message, no disabled state on the button. The guard is app/tools/image_editor/static/js/editor_overlay.js:1329 — `if (layer.canvasId === 'editor-canvas') return;` — an unconditional early return with no user feedback. The bottom layer is not conceptually undeletable; it is just the one that happens to be mapped onto the base editor-canvas by loadBoardLayers(). When there is more than one raster layer, deleting it should promote the next layer up into the base canvas (Photoshop lets you delete the Background when other layers exist). Only a single-layer stack has nothing to promote, and THAT case should disable/grey the button rather than no-op. Whatever the chosen behaviour, the button must never look like it worked and do nothing.

#833 fixed the SYMPTOM properly — a headless run now binds alc.context.scope from the asset path, so PROJECT_REGISTRY.current answers for the job. This is the root fix underneath it: a path-derived lookup should not need an ambient scope AT ALL. PathObject.asset_details (alc/path/path_object.py:996) reads PROJECT_REGISTRY.current five times — character/prop/dressing/environment/sequence registries. But already carries company and project. Asking a global which project we are in, while holding a coordinate that says so, is the whole bug class: it can only ever be right by luck or by someone remembering to bind a scope first. THE CHANGE IS SMALL. All five reads are inside that one property, and asset_details has NO other callers in the repo — the only references are the three inside PathObject.height. store_for(po) already exists in alc/services/project.py doing exactly this resolution, with a docstring saying falling back to the active project is the silent cross-project read it exists to prevent. So: asset_details resolves via store_for(self). DECISION 1 — what happens when the coordinate has no project. store_for raises ValueError rather than guessing. asset_details currently returns None for an unrecognised parent, and height then explodes with AttributeError on NoneType (that IS the #833 crash). Recommend: raise an error that NAMES the asset and project when the asset is genuinely missing, rather than returning None for callers to trip over. A missing asset should be loud (see the no-silent-fallback convention), and in-repo nothing depends on the None. DECISION 2 — a real inconsistency found while measuring, decide it here. PathObject.height (path_object.py:1016) reads: chr -> self.asset_details.physical_traits.height_cm or 170 env -> self.asset_details.height or 600 else -> self.asset_details.height or None The cookbook's CreateScaleCube does . For chr and env that else branch is UNREACHABLE — the / guarantees a truthy value, so an asset with no scale set silently gets a default cube instead of the warning the step was written to give. Either the defaults are right and the cookbook's warning is dead code, or the defaults are wrong and are hiding unset scales. Pick one and say so. OUT OF SCOPE: the other 130 PROJECT_REGISTRY.current call sites. They are legitimately ambient (a request, a DCC session) and #833's scope already grounds them. This ticket is only about lookups that are derivable from a coordinate they already hold. DONE WHEN: asset_details resolves from self.company/self.project via store_for; a farm job gets the right asset with NO scope bound at all; a missing asset or a projectless coordinate raises something that names what it was looking for; and decision 2 is implemented rather than left ambiguous.

Decide whether Status(code='nte') should carry started=True. A task sitting at 'Notes' means a reviewer requested changes on submitted work — that work demonstrably started — but nte is currently absent from STARTED_STATUSES, so anything deriving 'has work begun' treats it as untouched.

po.publish() copies source+render to the major version + publish location and commits the task MSD successfully, then raises AttributeError: 'PathObject' object has no attribute 'shot' at path_object.py:1681 (elif self.shot == 'SEQ') inside _update_downstream_statuses. PathObject has no 'shot' field (it's parent/child) so publish crashes AFTER it has already landed on disk, leaving downstream statuses unset. Fix the attribute (self.child / correct shot token). Repro: po.publish() on an amc version where parent=INT, child=SEQ.

app/tools/media/media.py::_load_reviews globs every reviews/*.json and calls review.media.ensure_thumb() on EVERY page render. With playlists (#419) the whole Media tool re-renders on each playlist mutation (create / add / move / remove / select), so a project with hundreds of flagged items pays a full manifest scan plus a per-file thumb existence check — and possibly ffmpeg/AlcSequence thumb generation — on every click. Generate thumbs at flag time (flag_for_review) and lazily from the thumb route, or cache the scan per request, so reading the Media page is a read.

alc/services/media/shot_audio.py resolves a previs shot's dialogue audio by assuming the svz task owns the timeline - exactly the assumption #1024 removed from ImportStoryvisTimeline, left in place here. TWO HARDCODINGS, BOTH IN shot_audio.py: * shot_block_type() globs 'scene_{seq}_timeline.json' under an svz_root derived by string-swapping /VERSIONS/render/ -> /VERSIONS/source/ - a scene-shaped filename on a constant task, which is the exact pair of assumptions #1024 named. * its fallback calls PROJECT_REGISTRY.current.script.get_scene(seq), which raises for a video: a board's parent is not in the project script's scene list. This is the same failure that produced "svz.refresh: scene 'theaxe' not found". WHY IT HAS NOT BITTEN YET: it is only reached when encoding per-shot mp4 previews with dialogue muxed in (alc/plugins/blender/create.py ~2045). Board previs shots do not encode previews yet. The moment they do, a board's shots either get no dialogue or throw, depending which of the two paths is hit first. THE FIX ALREADY EXISTS: alc/services/timeline.py resolves the timeline manifest for ANY coordinate via TIMELINE_OWNERS (shots->svz, videos->scr). shot_audio should ask it rather than rebuilding the path, and its block-type fallback should read the owning task's model rather than the project script's scene list. DONE WHEN: a board's shot resolves its dialogue audio through the same code path a scene's does; neither raises for a coordinate whose timeline is not owned by svz; and the dialogue/action distinction (action blocks stay silent) is unchanged.

scan_media_rows() parses a camera dir as {seq}_{block}_{take}_MagiCam and takes block=parts[1], take=parts[2]. That is right for a SCENE (010_0010_001_MagiCam) and wrong for a beat-board VIDEO, whose cams are named with the block LAST: E:/Alchemy/cgl/loj/VERSIONS/render/videos/theaxe/SEQ/prv/default/tom/000.014/high/010_010_0010_MagiCam - there parts[1]='010' (the scene) and parts[2]='0010' (the block). Every board therefore collapses into a single take_id key '010_0010' style pairing that does not match the script block ids the document emits (0010, 0020 ...). Anything joining a board's shots through scan_media_rows - the scene timeline media-rows endpoint, ensure_styled_offsets, and the cookbook shelf alchemy/shelves/prv/RenderStyleVideo.py which states the same {seq}_{block}_{take} assumption in its docstring - is keying board renders off the wrong token. WANTED: one place that answers 'which camera dir belongs to block X' for BOTH shapes. #1748 already added prv_media.previs_cam_dirs_by_block(render_dir, block_ids), which sidesteps the parse entirely by matching endswith('_{block}_MagiCam') against ids the caller already knows; the fix is probably to give scan_media_rows the same treatment (or to have it take the owning document's block ids) rather than adding a second parse rule.

PathObject.get_thumb_path(thumb_type='asset') is entity-type-agnostic: for a scene it resolves to PUBLISHES/render/shots/{scene}/SEQ/.thumb/thumb.png — the SAME .thumb/thumb.png convention as any asset, served via /alcroot/{path-relative-to-PROD_ROOT} (StaticFiles mount, app/main.py:214). Confirmed the path resolves for scene INT; nothing writes the file yet. Work: (1) During the animatic (amc) publish — and optionally previs — generate the scene's asset-level thumb .thumb/thumb.png from the animatic's first frame / preview, mirroring how the design (dsn) publish writes an asset's thumb (see AlchemyAsset.asset_thumb + PathObject.asset_thumbnail). Use the OIIO media service for the frame grab. (2) Add a SceneAsset.asset_thumb property (build a PathObject with entity_type='shots', parent=scene_id, child='SEQ', then get_thumb_path(thumb_type='asset')) returning {exists, path} root-relative, so templates consume it uniformly. Then app/templates/partials/asset_grid.html:133 (currently forces asset_thumb=None for Scenes) and the Tracker thumbnail column (ticket #329) can both display it with no special-casing. Unblocks #329.

ImportCharacterRigs lays the registered cast out on a grid starting at world origin (0,0,0). The MagiCams the timeline step creates sit at (-0.003, 0.0, 1.692). So the cast lands 0.31-1.56m in front of camera 010_010_0010, occluding that shot's image plane at 5.73m: a board previs opens as a dark mass with the beat art hidden behind jack's rig control shapes. NEITHER STEP IS WRONG ALONE - it is the seam between the grid origin (#1026) and the camera origin (#1024), which is why it passes every step's pass_criteria and was only caught by rendering frame 1 through the camera rather than inspecting the scene graph. FIX BELONGS IN THE PLACEMENT, NOT THE CAMERA: the cameras are where the board says they are. Offset the grid origin off the camera axis, or better, place the cast relative to the imported location's bounds rather than world zero - a cast standing inside the environment it is registered in is the honest default and stops being a coincidence of both origins being near (0,0,0). DECIDE AND STATE: whether placement is relative to the location bounds or a fixed offset, and what happens when no environment imported (no bounds to place against).

In create.py the overscan pre-pass is wrapped in a bare try/except that prints and continues: 'except Exception as exc: print(f"[overscan] pre-pass failed ({exc}); rendering hero framing")'. os_manifest stays None, the render proceeds at hero framing, and 90 lines later the manifest write is guarded by 'if os_manifest is not None' - so the shot renders perfectly, produces clay frames and mattes, and has NO shot_manifest.json. Nothing downstream can tell that shot apart from a good one by looking at it, and the style pass (which needs the manifest for its anchor frame and presence list) fails only when somebody spends a pass on it. The manifest-write except clause has the same shape. WANTED: a shot that renders without its manifest is a MARKED failure, not a print - the reason persisted beside the render (a .failed/.log sidecar, or the manifest written with an error field) so the state is inspectable after the fact, and the render reported as incomplete rather than successful. Re-rendering is not a workaround: the pre-pass throws again for the same shot-specific reason.

premiere/setup should own the port facts for headless rendering: the Alchemy app port (8080) and the AME web-service port. A preflight check confirms the AME web service is NOT configured on the Alchemy port and reports where it actually is, so the collision is caught by a check instead of by a failed render.

A premiere render module that submits a .prproj to the Adobe Media Encoder web service and polls to completion, with no Premiere and no UXP panel involved. Owns the service lifecycle the way the ComfyUI bridge does with ensure_running(): start ame_webservice_console.exe if it is not up, wait for readiness, submit, poll, return the real output path.

Determine what AME renders when a .prproj contains more than one sequence, then guarantee the pipeline never depends on the answer - most likely by having the publish step emit a project holding exactly the sequence we want rendered.

Farm-side headless Premiere rendering should resolve the AME web-service executable for the versions actually installed here (2025 and 2026).

POST /kanban/item/{id}/autosave writes the WHOLE form as it was rendered. If anything else edits the item between the modal's render and its autosave — the ticket CLI, a skill flow, another session — the autosave silently writes the stale values back over it. Last-write-wins, per-field, no conflict detection, and (worse) autosave leaves NO stamp in status_history, so the overwrite is invisible: updated_at doesn't even move past the legitimate edit it destroyed. PROVEN 2026-08-08 on ticket #3670: `ticket_cli edit 3670 --capability "Feature Attribution Workflow"` round-tripped and Tom SAW the value in his open modal; minutes later the field read '' on the board, no history entry, no registry mint at done-time. Server log shows the anonymous writer: GET modal -> POST autosave 204. The wrap-up capability flow (#3501/#3670) lost its input before it ran. Recovered by re-editing + re-running done — but only because a human was watching. This is the second stale-writer clobber this sprint (FeatureRegistry.commit() used to replace the on-disk document wholesale — fixed by merging onto disk). Same class, other store: the board. FIX DIRECTION (per-field merge, not locking the human out): 1. The modal form carries each field's RENDERED (original) value; autosave submits current + original; the server writes ONLY fields where current != original. An untouched field can then never clobber anyone. This also makes autosave idempotent for free. 2. Failing that, client-side dirty tracking (write only fields the user actually changed). 3. Autosave writes that DO change something leave a trace — a lightweight history/ledger stamp or at minimum a log line naming the fields, so a silent writer can never again be a mystery. 4. Keep the WorkBoard.editing() lock as-is — it correctly prevents torn writes; this bug is about STALENESS, which a lock cannot see. ACCEPTANCE: reproduce the #3670 sequence (open modal -> CLI edit a field the modal user never touched -> autosave fires) — the CLI edit survives; a field the user DID edit still saves; an autosave that changes nothing writes nothing; any field-changing autosave is visible in history or logs.

Audit every existing DCC plugin against the ontology as it stands after the fresh 3ds Max build, and produce a decision document + follow-up sprint plan rather than code. The Max build is the first plugin written entirely against the current contracts, so it is the clean reference: compare blender, maya, unreal and substance to it and report (1) which still carry the pre-contract root create/edit/query/delete vocabulary and how much, (2) task coverage per DCC against the smart_task contracts, (3) which contracts have no implementation anywhere, (4) where Max had to diverge from the reference implementations and whether the divergence should propagate back. Output is a written analysis with a recommended sequence of follow-on sprints, sized. Deliberately NOT an implementation ticket.

Port the Blender plugin off its pre-contract root vocabulary and onto the smart_task contracts, so blender dispatches the way unreal and max do. Scope the work first: alc/plugins/blender/create.py (2381 lines), edit.py (1934) and query.py (360) are still imported by roughly 52 cookbook steps across 77 call sites. Produce a per-phase, per-task breakdown of those call sites, then migrate them to get_task() / the tasks/{task}/{verb}.py modules, retiring the root modules when the last caller is gone.

default_executor() should fail loudly for a software id that is not registered, instead of silently handing back a BridgeExecutor. Today alc/plugins/smart_task/executor.py ends with an unconditional return BridgeExecutor(software=software), so any string at all - including a typo - yields a plausible-looking executor that only fails much later, at the socket, with a connection error pointing at the wrong problem. Raise (or at minimum warn) when software is absent from _DCC_PROBE. Then re-examine the acceptance criteria of the DCC-registration tickets that assert on this function.

Make a bare pytest run work again. Five modules under dev/ fail at import time, and because collection errors abort the whole run, plain pytest currently executes nothing at all - it exits on 5 collection errors before a single test runs. Either fix the imports, mark the modules as non-tests, or move them out of pytest discovery. Whichever way, the goal is that pytest with no arguments collects and runs the suite.

Write down the rule that makes verification inside a git worktree trustworthy, so parallel sprint agents stop silently testing the wrong tree. The package is installed editable into the shared venv by a finder that hard-points at the MAIN checkout, so a worktree agent running that venv can import alc from main and see none of its own edits. The finder is APPENDED to sys.meta_path, which means the stdlib PathFinder still wins when the worktree root is on sys.path - so the working rule is: run the shared venv interpreter with cwd set to the worktree root, use the -c or -m invocation forms (NOT python path/to/script.py, which puts the scripts directory on sys.path instead of cwd), and prove it with a print of alc.__file__ before trusting any result. Put this in the sprint skill and/or the plugins CLAUDE.md, wherever agents will actually read it.

Drop the hardcoded machine-specific sys.path fallbacks from the in-DCC bridge plugins once each DCC startup script sets the path itself. The Substance plugin (alc/services/ai/substance_bridge/painter_plugin.py) carries literal C:/Users/tmiko/... and E:/Alchemy/... roots, and the new Max plugin (alc/services/ai/max_bridge/max_plugin.py) inherited the same pair for consistency. Max already puts a __file__-derived repo root ahead of them plus an ALC_MAX_BRIDGE_PATHS env override; decide whether that pattern should be the standard, then remove the hardcoded pair from both. Check the other bridge plugins for the same thing while in there.

Make ExportInfo.units truthful per artifact instead of leaving the class default in place. ExportInfo in alc/models/version.py declares units with a default of cm, and nothing overrides it at publish time - so every MSD on disk claims cm regardless of what the file actually is. For a .glb that is simply wrong: glTF is metres by specification. A consumer that trusted the passport and converted from cm would shrink every model by 100x. Set units (and confirm up_axis and scale) from the artifact actually being written, at the point of publish, for every DCC leg that writes an MSD.

convert() reads an ExportInfo passport from a sibling .msd next to the source file and uses its up_axis to decide whether a corrective rotation is needed. That is right for a design glb, whose passport describes the file. It is WRONG when the sibling .msd describes the SCENE rather than the file being converted - which is exactly what a publish produces. Make the passport lookup only apply where the .msd genuinely describes the source file, or require callers to opt in, so a conversion that worked on the first run cannot break on the second because a sibling manifest appeared next to it.

Stand up alchemy-premiere as an MCP server instance. Premiere does NOT follow the Blender/Maya/Max shape, but the differences sit BELOW the MCP boundary and none of them are compliance obstacles: MCP defines client-to-server, and what the server does to reach its backend -- dial out, wait to be dialed, send Python, send JavaScript -- is invisible to the client. Serve MCP over Streamable HTTP mounted on the FastAPI app the bridge ALREADY runs on 20261, rather than stdio like the Python DCCs. Streamable HTTP is a first-class transport in the spec, not a downgrade, and this topology is cleaner: one process, one hop, and the server directly owns the /ws/panel WebSocket it needs. A stdio subprocess would instead have to open a second connection back to this app. Adding the MCP endpoint must not disturb the existing /exec, /menus, /menu/run, /todos and /request surfaces. Panel-not-connected is already first-class in the bridge (the panel WebSocket is None until it dials in, and there is a status endpoint) -- map that state to an isError tool result per #3895, with text telling the artist to open the Alchemy panel in Premiere. Never hang waiting for a dial-in.

Stand up alchemy-after-effects as an MCP server instance, completing the DCC set. AE's bridge is the same shape as Premiere's -- FastAPI + uvicorn on 20262, a CEP panel that dials OUT over /ws/panel, a status endpoint, and a panel reference that is None until the panel connects -- so serve MCP over Streamable HTTP mounted on that existing app, exactly as #3906 does. Reuse whatever adapter #3906 produces rather than writing a second one; if AE turns out to need its own, say so on the ticket, because that means the Premiere solution was too narrow. The one real difference is the exec payload: AE has no UXP, so the panel runs ExtendScript (JSX) through CSInterface.evalScript against the AE DOM (app.project, comps, layers, the render queue), where Premiere runs JavaScript. That difference sits below the MCP boundary and should not reach the tool surface. AE implements one task (vid) and generates zero tools until #3905 lands. Same rule as the other narrow DCCs: advertise only the ops AE actually implements.

The sprint-closing card: one parameterized conformance suite run against EVERY Alchemy MCP server (blender, maya, unreal, substance, max, premiere, after-effects) rather than seven per-DCC test files. Assert, for each: the initialize handshake returns a protocolVersion and the capabilities the server actually implements; tools/list is well-formed MCP (inputSchema, not input_schema) and every advertised tool is dispatchable; the advertised list matches that DCC's REAL task coverage, so no server offers an op its DCC cannot serve; a failing op returns isError with the message as content rather than a JSON-RPC error; a disconnected DCC returns an actionable message rather than hanging; and concurrent calls to one bridge serialize. Where a DCC is not running, the suite must SKIP with a clear reason, never silently pass -- a green run against seven closed applications would be the worst possible outcome here. --- AMENDED 2026-08-11 --- The suite must run across BOTH transports, not just stdio: five stdio servers (Blender, Maya, Unreal, Substance, Max) and two Streamable HTTP servers (Premiere on 20261, After Effects on 20262). The same conformance assertions apply to both -- handshake, well-formed tools/list, dispatchability, coverage matching real implementation, isError semantics, backend-unavailable behaviour, serialization. Transport must be a parameter of the suite, not a fork of it; two parallel test bodies would defeat the point of the card. Add one transport-specific assertion each: a stdio server must not write anything to stdout that is not a JSON-RPC message (log output on stdout corrupts the stream -- logging goes to stderr), and an HTTP server must leave the bridge's existing routes working while MCP is mounted.

Source hardcoded operational roots from config: LIBRARY_ROOT X:/ALC_MOTION in alc/models/motion.py, Deadline spool dir E:/Alchemy/temp/spool in alc/services/deadline/create.py + previs_plan.py, sys.path roots in alc/services/ai/max_bridge/max_plugin.py, and the absolute film_strip_border.svg path in alc/plugins/alchemy/tools/shot_navigator/ui.py. Current values become config defaults so Windows behavior is unchanged. Success test: grep for drive-letter literals under alc/ hits only docstrings/examples/dev-main blocks; app boots with all roots resolved via config; setting a POSIX root (e.g. /data/Alchemy) produces valid PathObject paths.

Make the server package importable on Linux: guard or lazy-load the win32/pywin32 imports in alc/config/env.py, alc/services/media/window_capture.py, and alc/plugins/after_effects/install.py so they load only at call time on Windows. Success test: on a Python without pywin32, 'from app.main import app' succeeds; calling window capture off-Windows raises a clear WindowsOnly error at call time, not import time.

Add a Dockerfile at repo root that builds the FastAPI web app on python:3.11-slim: installs ffmpeg + OpenImageIO tools (oiiotool), pip-installs requirements into the image, and CMDs uvicorn on :8080 (reload=False, matching the Windows-reload convention). Success test: 'docker build' completes from a clean checkout; 'docker run -p 8080:8080' starts with no import errors and GET / returns 200.

Add docker-compose.yml wiring the web app image to a host-mounted production root: Alchemy root + alchemy.json config provided via bind mounts/env vars, port 8080 published, restart policy set. Every required env var documented inline in the compose file. Success test: on a machine with only Docker installed, 'docker compose up' with a seeded sample project directory serves the app on :8080 and project pages render media from the mounted root.

Add a smoke-test script runnable against the composed container: key routes return 200 (shell, projects list, a project shots page), an exr-to-png conversion via the OIIO media service succeeds inside the container, and preview/thumb/proxy paths resolve under the POSIX root. Success test: script exits 0 against 'docker compose up' with the seeded sample project. This script IS the sprint acceptance gate: when it passes, the sprint is done.

MkDocs handbook page documenting the Docker deploy path: build the image, run locally via compose, deploy to a single EC2/VM (ports, volumes, config), and how to run the smoke-test acceptance gate. Success test: a reader with Docker and the repo can go from clean checkout to a serving instance using only this page.

Add a --test flag to the Alchemy entry point (venv and future frozen exe alike): boot the FastAPI app headless, request /, exit 0 on 200 or nonzero on any import/boot failure, within 25s. This is the same harness contract the old build scripts rely on (launch_alchemy(exe, --test) in cglumberjack build_win32.py/build_darwin.py). Success test: 'python -m app --test' style invocation exits 0 from a clean venv; breaking an import makes it exit nonzero with the traceback on stderr.

Adapt cglumberjack cgl/apps/alchemy/alchemy.spec + build_win32.py to this repo: Python 3.11, FastAPI server entry (no PySide6), collect app/static + app/templates + OTIO adapters as datas, keep the install_openimageio step (oiio_bin.zip from alchemy-dependencies-bin S3 into _internal/openimageio). Local one-command build - the old GH workflow yaml is the dependency spec only (Actions are dead org-wide). Success test: pyinstaller build from clean checkout produces dist exe; exe --test exits 0; running exe serves :8080 and GET / returns 200 with static assets loading.

Port cgl/apps/alchemy_installer (downloader, multi_file_download_manager, manifest_utils, updater, constants) into this repo: semver master-manifest with ordered_versions, per-version file manifests, cumulative-diff incremental updates from S3. Verify the old buckets (alchemy-windows, alchemy-windows-installer, alchemy-dependencies-bin) and AWS creds are still live, or re-point at current ones. Success test: on a machine without Alchemy, the installer exe downloads the latest manifested build and installs it; publishing a new version and running the updater applies only the diffed files.

Port generate_manifest, upload_alchemy_to_s3, update_master_manifest, get_next_alchemy_version so build_win32 ends with a versioned release: build, --test smoke pass, semver bump, upload, master manifest updated. One command from clean checkout to published release. Success test: running the build command publishes a new semver version to the bucket, ordered_versions in the master manifest includes it, and the installer/updater on another machine picks it up.

On a clean Windows machine or VM with no Python installed: run the installer exe, app installs, launches, serves the localhost UI, and connects to a remote Alchemy server over the tunnel. Write the checklist down as the repeatable release QA doc. Success test: fresh machine to working client without ever touching Python or a terminal; checklist passes end to end. This is the sprint acceptance gate.

Sign the built exe and installer with a code-signing cert so SmartScreen does not flag downloads for white-label clients. Success test: freshly downloaded installer on a stock Windows machine runs without the unrecognized-app SmartScreen interstitial (or shows the signed publisher name).

Stand up and document a local Mac build environment (GH Actions are dead org-wide; the paused alchemy-darwin-build.yaml is the dependency spec only): Python 3.11, PyInstaller, ffmpeg, fileicon (brew), AWS creds. Success test: a clean Mac following the runbook page reaches a successful PyInstaller build of the alchemy spec.

Adapt cglumberjack cgl/apps/alchemy/build_darwin.py to this repo on top of the shared PyInstaller spec: .app bundle, alchemy.icns, fileicon application, --test smoke launch. Success test: .app builds on the Mac build machine; open of the .app serves :8080 and GET / returns 200; --test invocation exits 0.

Port cgl/apps/alchemy_installer/build_darwin.py: build the Mac installer artifact against the shared manifest/updater infra, upload to the installer bucket. Success test: on a second Mac with no Alchemy, the installer downloads the latest manifested .app build and installs it; the updater applies an incremental version diff.

Sign the .app and installer with a Developer ID certificate, notarize via notarytool, staple the ticket. Without this Gatekeeper blocks the app outright on client machines - this is a hard requirement for distribution, unlike Windows SmartScreen. Success test: on a stock Mac with default Gatekeeper settings, the installed app opens normally with no right-click-open workaround.

On a clean Mac with no dev tools: run the installer, app installs, opens without Gatekeeper friction, serves the localhost UI, and connects to a remote Alchemy server over the tunnel. Write the checklist as the repeatable release QA doc. Success test: fresh Mac to working client without touching a terminal; checklist passes end to end. This is the sprint acceptance gate.

Build one small environment by hand from the concept: ground truth for layout accuracy and a timed baseline (the 'two days by hand' demo opening). Record what technical chores take the time.

Design the MagiCam UE plugin as a first-class NATIVE plugin with a store release as the bar: decide the boundary vs AlchemyUE (what ships on Fab with ZERO Alchemy/Python dependency: the rig, the native Camera Caddy panel, TVPaint import, lighting tools - vs what stays pipeline-side: Alchemy Timeline import, farm/publish hooks), the module layout (.uplugin + editor module reusing the native UI patterns from the AlchemyUE C++ module just merged to main - splitter/named-slot Slate/UMG work from the Unreal Alchemy Plugin sprint), the engine-version matrix (5.6/5.7/5.8 recompiles, keep the C++ surface dumb so the matrix stays cheap), asset strategy (Control Rig asset + BP generated from magicam_rig_spec.json vs baked content), and licensing (the Blender extension is GPL-3.0 - the UE plugin is a separate codebase and must NOT inherit that; pick a store-compatible license). Deliverable: a design doc next to MAGICAM_PORT.md + a compiling skeleton plugin. --- AMENDED 2026-08-13 --- BOUNDARY SHARPENED (Tom, 2026-08-13). The original spec framed this as a binary - what ships with ZERO dependency vs what 'stays pipeline-side: Alchemy Timeline import'. The real line is not which FEATURES ship, it is who ORCHESTRATES, and Tom drew it in two statements: 'Alchemy Timeline is a shape - a .json file - that translates to a model that's readable as an import artifact - we don't want to be so closed off that we can[not] run functions from it. With blender for example we do both.' 'But we have core python functions that can run things, so a timeline build would be outside of the core functionality of this plugin.' THE PLUGIN IS A CAPABILITY SURFACE, NOT AN ORCHESTRATOR. CORE (ships on Fab, self-contained, zero Alchemy dependency): the MagiCam rig, the native Camera Caddy, TVPaint clip_export.json import, the lighting tools. These are things a Fab customer with no Alchemy install uses standalone. TVPaint import is core precisely because it is a MagiCam-native feature, not an Alchemy one. NOT CORE: building a timeline. Assembling a previs from an Alchemy Timeline is Alchemy's core Python functions orchestrating - read the timeline model, then call plugin capability per shot. That work lives pipeline-side (cookbook + alc/plugins/unreal) and is exactly what #1008 is. The plugin does not own it and should not grow a timeline builder. THE REQUIREMENT THIS PUTS ON THE ARCHITECTURE - and it is the important one: The plugin must be OPEN. Every core capability has to be reachable from outside the plugin, so Alchemy's Python can drive it: rig creation, camera-per-shot, plate assignment, plane depth, lens, keying. In practice that means the C++ surface is exposed (UFUNCTION / BlueprintCallable, editor-scriptable and reachable from the Python plugin when it is present) rather than sealed inside Slate button handlers. A capability that only a panel click can reach is a capability Alchemy cannot orchestrate. So the design rule for every core feature: the PANEL and ALCHEMY are two callers of the SAME underlying op. This mirrors what the pipeline side already does - cam.edit verbs are the single source of rig behaviour, and the PySide caddy is just one caller. Keep that shape when it goes native. The Alchemy Timeline JSON matters as the INTERCHANGE SHAPE, not as something the plugin must parse. Deciding whether the plugin also reads it natively is optional and can be deferred - note the cost if it ever does: a store plugin in the wild would then be reading files produced by Alchemy versions it has never heard of, which turns an internal format into a published, versioned contract. Not owning the timeline build avoids paying that. Related: #4011 is doing the equivalent for AlchemyUE (native transport + tab registration, running without the Python plugin). Do not make PythonScriptPlugin a hard dependency of the MagiCam plugin the way AlchemyUE.uplugin does - feature-detect it. --- AMENDED 2026-08-13 --- SEQUENCING CHANGED - PYTHON FIRST, NATIVE PLUGIN AFTER (Tom, 2026-08-13): 'I also think we're going to have to have a certain measure of magiCam code in python simply to allow alchemy to function well. For the first pass of getting all this to work in Unreal we can potentially remove some of the stringent "this must be a plugin in UE" requirements and save that for after we have a working pipeline - and it sounds like we want to start with Python to make this as easy to build as possible (and we already have a lot of the working code for that).' So the store-plugin bar is NOT the bar for the first pass. Build the Unreal previs path in PYTHON against what already works, prove the pipeline end to end (#1008 is the acceptance test), and port to C++/Slate afterwards once the shape is known. This does not weaken the boundary recorded above, it re-orders it. The rule that survives untouched is the important one: the panel and Alchemy are two callers of the SAME underlying op. A Python-first implementation satisfies that just as well as a C++ one - cam.edit verbs are already the single source of rig behaviour and already have two callers. Why this is the right order, concretely: - The per-shot half is ALREADY BUILT and proven in Python: create_magicam_from_shot, _register_in_sequence, _ensure_level_sequence, camera cuts, media sections, _fit_playback_range, _key_rig_pose. Rewriting that in C++ before anything has assembled a full timeline would be porting an unproven design. - A 'certain measure of magiCam code in Python' is permanent, not scaffolding: Alchemy orchestrates the timeline build (see the boundary note above), and that orchestration is Python by definition. The Python layer is not a stepping stone to be deleted - it is the Tier-2 side of the two-tier model. - What the C++ port then owns is the CORE: rig, native caddy, TVPaint import, lighting - the things a Fab customer uses with no Alchemy present. Practical consequence for this ticket: #3982's 'compiling skeleton plugin' deliverable can be deferred. The design doc still has value NOW (boundary, module layout, engine matrix, licensing) because it is what the Python-first work should be shaped to become - but it should be written knowing the first implementation is Python, and it should record which Python surfaces are expected to migrate into the C++ core later. Knock-on for the sprint: #3983 (native Camera Caddy) and #4015 (retire the PySide caddy) both sit behind the native plugin existing, so both move later than #1008. The PySide caddy is therefore load-bearing for longer than the supersede note on #3983 implies - do not retire it while the Python path is the working pipeline.

cam.edit.select_control calls engage_rig with the default adopt=True, so pressing a Main/Dolly/Height/Tilt control button can write a stray Control Rig binding into whatever Level Sequence happens to be open. The native Camera Caddy deliberately passes adopt=False when a camera is picked, but that care is bypassed one layer down the moment a control button is pressed. Thread an adopt parameter through select_control (default False for UI-driven calls, or resolve the rig's own shot sequence rather than adopting the open one), and make the panel pass it explicitly. Acceptance: with an unrelated sequence open, pressing a control button on a rig that no shot sequence carries must not add a binding to that open sequence.

Nearly every surprise in the first real day of driving the UE tools was a dependency on AMBIENT STATE nobody declared - the tool adapted to whatever it found instead of establishing what it needs, so problems were discovered by tripping over them. Real examples from 2026-08-14: Sequencer's camera-cut lock was globally ON (set by an unrelated legacy op) and hijacked three viewports; the AlchemyUE plugin was absent from the project so a C++ panel silently did not exist; the bridge was not listening so the panel sat disconnected in silence; the Control Rig asset was not resident so controls did not draw; the component's transient mapping was stale so drags moved nothing; viewport Realtime decides whether a drag reaches the camera at all. Build a DECLARED STATE contract: (1) name the state Alchemy requires of an editor session - plugin installed and enabled, bridge connected, viewport layout established (#4082), camera-cut lock off unless a feature asked for it, Realtime on, rig asset resident, mapping valid; (2) a CHECK that reads all of it and returns a per-item pass/deviation report, cheap enough to run on demand and non-mutating; (3) an ASSERT that puts the session into that state (Set Layout is one piece of this, not a standalone feature); (4) SURFACE it - the caddy / Alchemy panel shows 'N things are not as expected' with what and why, instead of the tool behaving strangely and the artist guessing. Also expose the check as a PREFLIGHT the app can run BEFORE launching the editor, so a project missing the plugin is reported on the location card rather than discovered inside UE. Design the state list as data (one place naming each item, how to check it, how to assert it, and whether asserting is safe) so adding an item later is a data change - same shape as the rig spec driving the rig, validator and docs.

A store user has no Alchemy Python bridge, so the plugin itself must be able to create a MagiCam rig: ship magicam_rig_spec.json + the spec shape curve data as plugin content, and implement Create MagiCam Rig natively (editor C++ or baked assets regenerated at build time) producing the same BP + Control Rig asset that #345 authors over the bridge - identical control names, hierarchy main->dolly->height->tilt, per-channel locks/limits, wire shapes from the spec polylines, camera under tilt, 10 autoscaling planes with opacity material. The spec JSON stays the single source of truth: plugin build regenerates assets from it rather than hand-maintaining a second rig definition.

Wire the #3980 parity validator UE adapter to the natively-generated rig and make a green run the release gate for every plugin build: control-by-control conformance (names, hierarchy, locks, limits, shapes, attachments) plus the behavior probes (plane autoscale, lens snap) against a rig created by the plugins own Create MagiCam Rig - proving the native generator, the bridge-side builder and the Blender rig all satisfy the same spec. Add a one-command runner suitable for pre-release (headless editor commandlet or scripted editor run).

Everything between a working plugin and a store listing: Fab submission compliance (self-contained, no external Python/pip deps in the shipped plugin, naming/category/metadata rules), builds for the supported engine matrix, a demo map with a rigged sample shot showing the caddy driving the rig, documentation (quickstart + per-control reference generated FROM the rig spec so docs cannot drift from behavior), screenshots/video capture for the listing, versioning + changelog convention, license text, and a submission checklist with the pricing/free decision left explicitly for Tom.

The lens_chooser control is the lens preset slider (travel clamped to +/-47.25, snapping focal length through 16/24/35/50/85/120/200) but reads as a bare cube with nothing to slide along - Tom left it untouched in a shape-tuning pass because he could not tell what it did. DO NOT solve this by building a track and label strip into the Control Rig yet. Tom's direction 2026-08-13: the lens interaction will most likely live in the MagiCam Camera Caddy UI we are going to build (#3983), so building a full slider rig-side first risks duplicating it. What he DOES want preserved is the principle: being able to change the lens directly in the viewport without going to a panel is valuable and should survive whatever the caddy does. So: sequence this after #3983, then decide the split - what the caddy owns vs what stays a grabbable in-viewport control - and give the rig-side control only as much visual affordance as that decision needs.

Delete the PySide Camera Caddy once the native UE panel (#3983) is real and in use, so the rig has ONE control surface instead of two drifting ones. Tom, 2026-08-13: 'once the plugin exists, i don't care about this pyside ui anymore.' The native panel supersedes it - the PySide caddy is a reference implementation while #3983 is being built and a dead surface after. Scope: - alc/plugins/alchemy/tools/camera_caddy/ (the widget package, incl. its __main__ standalone entry) - alc.plugins.unreal.tools.launchers.launch_camera_caddy and its re-export from alc/plugins/unreal/tools/__init__.py - the cookbook's Camera Caddy button, if it still points at the PySide launcher (see #339, cb-unreal-menus-alchemy) - re-point it at the native panel rather than deleting the button - any docs/menu entries naming the PySide caddy Do NOT touch cam.edit. The verb layer is the single source of rig behaviour, it outlives both UIs, and that is precisely what makes this deletion cheap. Nothing in this ticket should change rig behaviour - if removing the UI requires a verb change, the native panel was not actually at parity and that belongs back in #3983. Acceptance: the native panel does everything an artist used the PySide caddy for, the PySide package is gone, no import of it remains anywhere, the test suite is green, and the Camera Caddy entry point an artist reaches from the Alchemy menu opens the NATIVE panel.

Port the MagiCam TVPaint importer natively: parse clip_export.json (TVPaint 11 AND 12 schemas - layer schema identical, clip/camera-level fields differ), build one MagiCam rig per clip with its layers on depth-staggered image planes, textures assigned, plane visibility per layer, matching what magicam/blender build.py does on import. C++ JSON parsing in the plugin (no Python dependency for store users).

Give the 'sch' production task a smart task that OWNS the schedule's data — MSD creation and reading — so a schedule versions up and publishes like every other task, instead of living as loose JSON in the cookbook. Three layers, and the point of the ticket is putting each value in the right one: 1. COMPANY DEFAULTS — the cookbook. Default head count per department (today hardcoded as DEFAULT_SEATS = 5 in alc/services/schedule.py:~57), default day rate, and anything else that is a studio norm rather than a decision about this film. Tracked cookbook config, the fallback a new schedule starts from. 2. THIS SCHEDULE'S VALUES — the MSD for the sch task, versioned and publishable. project_start, target_end, headcounts, row_order (the hand-ordered rows from #4185), deliveries, day_rate, milestones. The schedule is fluid — head counts get argued over — so these are decisions about THIS plan, they need history, and a re-plan must not silently overwrite the plan the crew is working to. 3. VIEW STATE — stays local, never production data. day_px (zoom), collapsed lanes, and the 'groups' category filter are how one person is looking at the chart. Deliverable: - Add alc/plugins/smart_task/sch.py — a SmartTask subclass for 'sch' (the code already exists in production_tasks.json as 'sch | Schedule'; there is simply no brain for it, unlike dsn/mdl/rig/tex/ldv/edt/amc/prv). Give it an msd_data_model for the plan payload and get_msd_data() composing it. SmartTask already supplies the rest: .msd validates the payload, and commit_version() writes path_object.version_msd.data and commits (alc/plugins/smart_task/task.py:217-277) — that IS version-up-and-publish. - Rewire app/tools/schedule/schedule.py to ask the smart task rather than the filesystem. Delete _config_dir/_settings_path/_load_settings/_save_settings and the deliveries equivalents (schedule.py:47-84), and the routes that write them (/settings, /settings/anchor, /settings/reset, /settings/row-order, /settings/row-order/clear). - Follow the Bid tool's publish shape where it fits: the Schedule already reads the latest PUBLISHED bid from prd/docs/bid (app/tools/bidding), so a published schedule becomes an artifact the rest of the pipeline can point at the same way. - Migrate what exists rather than dropping it — see notes. --- AMENDED 2026-08-21 --- MECHANISM — corrected after reading the code. MSD is 'Magic Scene Description' (docs/architecture/msd.md). There is NO msd.get()/set() API: task-scoped data is stored by resolving a PathObject for the task coordinate, writing into its version manifest's free-form data dict, and committing. po = resolve_location(project_id, sync_root='VERSIONS', entity_type='assets', parent='prd', child='docs', task='sch', user=CFG.alc_user, version='000.000', recipe_type='publish') if not po.task_msd.user_versions: po.start() vmsd = po.version_msd; data = dict(vmsd.data or {}) data['schedule'] = plan; vmsd.data = data; vmsd.commit() Working head is 000.000. version_msd at alc/path/path_object.py:996; VersionManifest.data at alc/models/version.py:194, commit() at :507. VERSION UP AND PUBLISH follows the Bid tool exactly (app/tools/bidding/bidding.py:1660-1720): ensure_working_version(po) — po.start() first time, else po.version_up_minor(copy_source_files=False) (the helper lives at app/tools/script/script_viewer.py:350-358) — write the payload into new_po.get_source_path(dirname=True), then new_po.run_cookbook(recipe_types=['publish']). The publish recipe major-bumps and pushes the tracker. Read published versions back the way _bid_versions/_published_payload do (bidding.py:883-927): majors X.000, excluding 000.000. THE POINT OF THE SMART TASK: Bid does all of the above INLINE in the web tool. That is the thing to not repeat. The sch smart task owns MSD creation/reading and the version/publish calls; app/tools/schedule/schedule.py asks the smart task and never touches PathObject, version_msd or run_cookbook itself. Today the Schedule tool touches none of them — its only pipeline touchpoint is reading the published bid via _latest_bid (schedule.py:141-149). GROUNDWORK THAT ALREADY EXISTS: prd/docs is a production-documents-only pseudo-asset accepting scr/bid/sch/dck (alc/services/project.py:31); 'sch | Schedule' is a registered production task in the cookbook's production_tasks.json (verified against the live cookbook — 32 codes, sch present); and a cookbook 'alchemy/start/sch' recipe is already referenced (docs/guides/porting-a-dcc.md:336). What is missing is any Python that constructs a prd/docs/sch PathObject — a repo-wide grep finds none. FULL SETTINGS INVENTORY to place across the three layers — project_start (:317), target_end (:318), groups (:343), collapsed (:347), day_px (:363), day_rate (:375), headcounts (:382), row_order (:434). Two more are computed per render and never persisted: priorities and milestones (schedule.py:245-253). Deliveries live in a separate sidecar with records shaped {id, name, date, scene_ids, asset_ids} (schedule.py:560-565); asset refs are 'group:slug' resolved live against the registries. POST /settings/reset currently keeps only project_start and groups (schedule.py:405-412) — that split should be re-derived from the three layers rather than preserved as-is.