feat(tools): mavis creative pipeline v0 - sketch + prompt -> theme.skin JSON - #2450
Merged
Merged
Conversation
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (20)
📝 WalkthroughWalkthroughThe PR adds MiniMax H3 ULTRA ComfyUI installers, a ComfyUI REST client, Pinokio launcher, sketch-to-skin rendering, tests, documentation, and a persona living-document route. ChangesCreative Pipeline
Persona Living Document Route
Estimated code review effort: 4 (Complex) | ~60 minutes Suggested reviewers: ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
POWERFULMOVES
marked this pull request as ready for review
August 7, 2026 20:15
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
added 8 commits
August 7, 2026 20:39
Add /persona/livingdoc route handler that serves the full persona room directory (HTML5, CSS, JS, video, fonts, PreTeXt output) from the volume-mounted rooms/persona/ path. Includes path-traversal guard and correct MIME types for binary assets (mp4, woff2, images). Add personalized "Welcome back, <name>" greeting to the dashboard header using useSupabaseAuth — extracts display name from email or user_metadata. Fix /dashboard/rooms crash when a room manifest has no policies block (null guard with optional chaining + fallback to 'default'). Add the missing policies block to jons-edge.room.control.json. 💘 Generated with Crush
…on foundation CLAIM the creative-pipeline v0 lane in AGNOTE4482PHI.t1 per three-body collision-avoidance. Companion to today's OPENROOM-REALIZATION-SLICE-2-CLAIM. Scope: the integration foundation that turns Cataclysm Studios sketch archive (G:\My Drive\CataclysmstudiosInc\Pictures\) + 82 SoundCloud tracks into the production substrate for the music video + AI comic + CHIT viz pipeline. Pillar 4 skin (cyber.png -> theme.skin), beat-to-room generator, and CHIT tour re-skin all needed the same Mavis->ComfyUI+Pinokio wire. First trail entry for creative-pipeline v0. Subsequent commits land the install scripts, workflow JSONs, HTTP client, Pinokio launcher, render glue, and tests.
…s) w/ attribution Three install paths from Aitrepreneur's MiniMax H3 ULTRA V1 setup, copied verbatim from the operator's Downloads/SEAP/ folder: - install/MINIMAX_H3_ULTRA-AUTO_INSTALL-RUNPOD.sh - one-shot RunPod installer (PyTorch 2.8.0+cu128, 5 custom nodes, 6 model files via HF Xet w/ resume, final dep check, auto-launch) - install/MINIMAX_H3_ULTRA-COMFYUI-MANAGER_AUTO_INSTALL.bat - one-click Windows portable installer (downloads ComfyUI_windows_portable.7z, clones nodes, downloads models, launches run_nvidia_gpu.bat) - install/MINIMAX_H3_ULTRA-MODELS-NODES_INSTALL.bat - safe add-on installer for existing ComfyUI (locks pip env, adds 5 nodes with sanitized deps, downloads missing model files only, /update /force /dryrun /restore flags) Plus install/README.md (decision matrix: RunPod vs Windows portable vs existing ComfyUI) + install/ATTRIBUTION.md (Aitrepreneur credit, model provenance from Aitrepreneur/FLX HF repo, pinned dep versions, HF_TOKEN note for the gated repo). Scripts are unmodified - the operator's local files are canonical. Aitrepreneur is the upstream author; we ship these as artifacts so fresh local models (Spark, Knuckles) can reproduce the H3 host without needing the operator's local SEAP folder. Follow-up commits in this slice land the workflow JSONs, the comfyui_client.py HTTP wrapper, the pinokio_launch.sh wrapper, and the render_skin.py pipeline glue.
…turbo-LoRA) Two exported ComfyUI workflow JSONs from the Aitrepreneur MiniMax H3 ULTRA setup, copied verbatim from the operator's Downloads/SEAP/ folder: - workflows/MINIMAX_H3_ULTRA_WORKFLOW.json (~250KB) - standard full-quality sampler chain. ~3-5min render at 5s 720p on RTX 4090. Use for hero shots, music video clips, final renders. - workflows/MINIMAX_H3_ULTRA_+TURBO-LORA_WORKFLOW.json (~252KB) - the default. Loads minimax_h3_turbo_4step_ckpt500_comfyui_pruned.safetensors LoRA for 4-step sampling. ~30-60s render at 5s 720p. Use for iteration, concept work, skin renders, storyboards. Both wire the full 6-model H3 stack (Qwen3-VL 32B text encoder, FL2VA T2V/I2V diffusion, REF2VA reference video, video + audio VAEs, optional turbo LoRA). Both expose the variable inputs (SEED, HEIGHT, Video Duration) as INTConstant / RandomNoise / PrimitiveFloat so the upcoming render_skin.py can override them per call. Both depend on the ComfyUI-Spectrum-MiniMax-H3 custom node (cloned by the install scripts). Plus workflows/README.md - the decision matrix (turbo vs standard), what's in each workflow, custom node requirement, editing workflow, and why these specific exports (full 6-model stack, API format, pinned sampler chain via Spectrum). The Mavis client (comfyui_client.py, next commit) defaults to the turbo-LoRA workflow because Pillar 4 skin renders and beat-to-room stills prioritize iteration speed. Set PMOVES_COMFYUI_WORKFLOW to override per-render.
…A host Synchronous Python wrapper around the ComfyUI REST API. Four-method surface: health, submit, wait, download. Returns a RenderResult dataclass that the upcoming render_skin.py can iterate over to drop outputs into a theme.skin JSON. Design notes (in the module docstring): - Centralizes PMOVES_COMFYUI_URL / PMOVES_COMFYUI_TIMEOUT_S / PMOVES_COMFYUI_POLL_S env vars so render_skin.py doesn't repeat them. - Polls /history with exponential-backoff-friendly sleep (fixed poll_s for now, future-proofed for backoff if the slice grows). - Translates the ComfyUI history entry into OutputAsset records (handles images, gifs, videos, audio - the four output kinds H3 workflows can produce). - CLI mode: submit a workflow JSON, optionally override the CLIPTextEncode text + LoadImage filename, wait for completion, print the output paths. Used by render_skin.py via direct calls but also runnable by hand for debugging. Edge cases handled in the code: - UnicodeDecodeError on /view (binary image data) - returns raw bytes. - Missing prompt_id in /prompt response - raises ComfyUIError. - Render errors flagged in /history status - RenderResult.status="error" so the caller can decide whether to retry. - Timeout via PMOVES_COMFYUI_TIMEOUT_S - raises ComfyUIError with the prompt_id for log correlation. Tests in pmoves/tools/tests/test_comfyui_client.py - 12/12 pass: - HealthTests: OK + unreachable - SubmitTests: prompt_id returned + missing-field error path - WaitTests: success + error status + timeout - DownloadTests: writes PNG bytes to dest - BuildResultTests: parses all 4 output kinds (images/gifs/videos/audio) - ApplyOverridesTests: text + image override paths - EnvDefaultsTests: env vars override base_url/timeout/poll_s No actual ComfyUI host required for the tests - all httpx calls mocked via urllib.request.urlopen patching.
…launcher Shell wrapper that lets Mavis launch any Pinokio app (comfyui, ace-studio, veo-blueprints, comfyui-manager) and wait until it's actually serving requests, not just until pinokio start returns. Why a wrapper: 1. Idempotency - if the app is already running, pinokio start fails. The wrapper checks the port first and no-ops if up. 2. Readiness polling - pinokio start returns as soon as the launch command is submitted, not when the app is serving. The wrapper polls the app's port via a Python socket connect (cross-platform, works on Linux + macOS + Git Bash on Windows; the bash /dev/tcp redirect is unreliable on Git Bash). 3. Consistent exit codes - pinokio's exit codes vary by app. The wrapper normalizes to 0 (ok), 1 (no pinokio), 2 (no app), 3 (start fail), 4 (timeout) so render_skin.py can branch on True. 4. Python3 fallback - detects python3 vs python (Git Bash on Windows often has no plain python). CLI: pinokio_launch.sh <app> [--timeout S] [--port PORT] [--no-wait] Env vars: PINOKIO_BIN (default: pinokio), PINOKIO_HOME (default: \C:\Users\russe/.pinokio), PINOKIO_API_HOST (default: 127.0.0.1). Tests in pmoves/tools/tests/test_pinokio_launch.sh - 8/8 pass. Uses a fake pinokio binary (tests/_fake_pinokio.sh) that simulates the launch behavior: install a fake app dir, optionally bind a port, optionally fail the start command. The wrapper's exit codes are all exercised. Tests: - missing arg -> exit 1 - no pinokio binary -> exit 1 - app not installed -> exit 2 - launch + wait for ready -> exit 0 - --no-wait returns after start -> exit 0 - start fails -> exit 3 - timeout when port never opens -> exit 4 - already-running is a no-op -> exit 0
…ne glue The Mavis pipeline glue. Takes a sketch from the Cataclysm Studios archive + a text prompt, submits a MiniMax H3 ULTRA workflow to ComfyUI, downloads the output image(s), and writes a theme.skin JSON that the pmovesRoomAdapter.applyTheme consumer (PR #2437 P6) can pick up. Three-step render: 1. _patch_workflow(workflow, prompt, sketch, prompt_id_holder): - Finds the positive CLIPTextEncode node by title match ("positive" or "prompt") and patches widgets_values[0] with the prompt - Stages the sketch into pmoves/tools/comfyui/_input/ (or PMOVES_COMFYUI_INPUT_DIR override) and patches the LoadImage widget to point at it - Computes a stable prompt_id from the patched workflow hash so re-running the same sketch + prompt is cache-friendly 2. client.submit(workflow) + client.wait(prompt_id): - ComfyUIClient handles the HTTP /prompt + /history polling - Renders can take up to PMOVES_COMFYUI_TIMEOUT_S (default 600s) 3. _pick_assets(saved_images): - Smallest image -> theme.icon (favicon-sized) - First image -> theme.skin (the canonical reference) - Largest image -> theme.wallpaper (full-bleed background) - If only one image, all three point at it (consumers fall back) Output JSON schema (pmoves.theme.skin/v1): { "schema_version": "pmoves.theme.skin/v1", "theme_skin": "renders/out.png", "theme_icon": "renders/icon.png", "theme_wallpaper": "renders/wall.png", "css_vars": {}, "data_attrs": {"skin-source-sketch": "...", "skin-workflow": "...", "skin-prompt-id": "..."}, "meta": { "source_sketch": "G:\\My Drive\\CataclysmstudiosInc\\Pictures\\cyber.png", "prompt": "Pillar 4 encoding visual, third eye, 6-eye motif", "workflow": "pmoves/tools/comfyui/workflows/MINIMAX_H3_ULTRA_+TURBO-LORA_WORKFLOW.json", "workflow_name": "MINIMAX_H3_ULTRA_+TURBO-LORA_WORKFLOW", "rendered_at": "2026-08-06T18:30:00+00:00", "comfyui_url": "http://localhost:8188", "prompt_id": "abc123", "status": "success", "title": "Pillar 4 encoding", "source_attribution": "Cataclysm Studios / DARKXSIDE archive" } } The schema_version field pins the consumer contract: a future change can roll out with a versioned fallback. CLI: python -m pmoves.tools.render_skin <sketch> <prompt> \\ --output pmoves/design/skins/<skin>.json \\ [--workflow <workflow.json>] \\ [--meta-title "..."] [--meta-source "..."] Tests in pmoves/tools/tests/test_render_skin.py - 14/14 pass. Coverage: - PatchWorkflowTests: positive prompt gets the override, negative is unchanged, LoadImage gets the staged filename, prompt_id is stable for same input, prompt_id differs for different input - StageSketchTests: sketch lands in input dir - PickAssetsTests: smallest=icon, largest=wallpaper, first=skin - SkinSerializationTests: schema_version is present, all fields serialize - WriteSkinTests: SkinResult -> JSON file at dest - RenderSkinErrorTests: missing workflow, missing sketch, unreachable host all raise the right error class - RenderSkinHappyPathTests: end-to-end with a mocked ComfyUIClient, verifies the full pipeline (patch -> submit -> wait -> download -> skin) No actual ComfyUI host required for the tests. Plus pmoves/tools/comfyui/README.md - the high-level map of the sketch -> render -> skin pipeline. Documents the directory layout, the workflow, and the 5 most common operator commands. This is the file future Spark / Knuckles sessions will hit first to understand the creative-pipeline integration.
Mavis convention per the operator's "review lessons > review comments" framing: every PR gets a LEARNINGS file tracking the 5-class taxonomy (legit/already-fixed/owner/out-of-scope/pre-existing) + the 4-bucket learning signal (missed-signal/fix-pattern/wrong-suggestion/already-addressed). This is the initial slice (no review cycles yet), so the buckets are empty placeholders. As review comments come in on PR #TBD, this file becomes the durable record of what was learned - more durable than the resolved thread in opaque GraphQL. Files in the slice: - pmoves/tools/comfyui/README.md - high-level map for future agents - pmoves/tools/comfyui/install/ - 3 Aitrepreneur H3 ULTRA installers - pmoves/tools/comfyui/workflows/ - 2 H3 ULTRA ComfyUI workflow JSONs - pmoves/tools/comfyui_client.py - HTTP wrapper for the ComfyUI host - pmoves/tools/pinokio_launch.sh - Mavis bridge to the Pinokio launcher - pmoves/tools/render_skin.py - sketch + prompt -> theme.skin JSON - pmoves/tools/tests/test_* - 34 tests, all pass Acceptance criteria (5/5 met) + tests (34/34 pass) + what this slice does NOT do (the 5 follow-up paths from the trail entry's "Left Behind" section) are all in this file.
POWERFULMOVES
force-pushed
the
feat/mavis-creative-pipeline-v0
branch
from
August 8, 2026 00:40
4b14342 to
ebe1bca
Compare
github-actions
Bot
added
docs
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 8, 2026
…2478) `3c7326a1a` (PR #2450, mavis creative pipeline v0) replaced an 82-line region of the Active Claim Register with 14 lines: 6 insertions, 74 deletions. The 6 insertions were the creative-pipeline entry written TWICE (the duplicate being the corrupted copy removed in #2476). The 74 deletions were six unrelated entries, none of them mentioned in that PR. Lost: Mavis::ENV-LOCAL-STRAGGLERS-2026-08-05 (PR #2415) Mavis::VALIDATE-COMPOSES-TAC-RATCHETS-2026-08-05 (PR #2416) Mavis::VALIDATE-DOCKERFILE-PATHS-RATCHET-2026-08-05 (PR #2417) 4090-claude::MINT-TOKENOMICS-FORKSYNC-TAC-YT-EGRESS (PR #2457, merged 20:52) 4090-claude::AUDIO-SEGMENTATION-TRUNK-INVENTORY (PR #2457, merged 20:52) 4090-claude::CLAIM-REGISTER-VERIFICATION-SWEEP (PR #2465, merged 21:24) #2465 and #2457 merged at 20:52 and 21:24; #2450 merged at 21:00 and 21:24 from a base that predated them, so their content was silently reverted minutes after landing. Classic stale-base overwrite on an append-only shared doc — the register has no gate that would notice, because a deletion is a valid diff. Restored verbatim from `3c7326a1a^` and re-inserted at the same anchor (immediately after the CRUSH-GLM52 CIPHER-TENSORZERO-S5-OPENROOM mark), so document order is unchanged from before the loss. Verified after the edit: all six GRAPHITI_MARKs present exactly once, the two entries #2450 legitimately added (creative-pipeline v0, openroom slice 2) still present exactly once, zero conflict markers, +81/-0. Nothing here is mine to close — the three Mavis lanes stay Mavis's under Village Rule. This restores the record only. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 8, 2026
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 8, 2026
…n the enumeration (#2482) * docs(ws2): claim the tooling-audit workstream + correct three items in the enumeration z890's coordination plan assigns Workstream 2 to this node by affinity. This claims it — bounded to five enumerated items, not to "tooling" as an area — and records the corrections the enumeration needs before either node builds on it. Corrections, all verified against origin/main @ 22c78fb: (a) 2 leaking copies, not 4 drifting implementations. Both shell scripts already carry the #2473 buildx fix (pmoves-disk-cleanup.sh:52, docker-fleet-cleanup.sh:43). Only infra.mk:89 and ci-expedition/SKILL.md:69 lack it. (b) 4090's own earlier "13 of 15 fork services" figure was WRONG — it double-counted services re-declared across the generated split overlays. Correct count is 7 unique sibling-context builds in docker-compose.yml, plus n8n, plus hf-mcp-server.yml which the handed-over list missed. (c) The ci-expedition fix is narrower than "PR head, not default". In that row `issue_comment` and `push` are correct; only `pull_request_review` is wrong. Surgical edit, not a row rewrite. Plus: the four .worktrees/* skill copies are checkouts of the same tracked file, so fixing main fixes them all — one item off the list. Evidence for (c) is empirical, from the #2479 fix rather than from docs: run 31257145963 (PR head pre-fix, main already fixed) ran the OLD workflow and failed at checkout; run 31257247543 (head rebased) ran the NEW workflow and went green. Default-branch resolution predicts the opposite. Not claimed and deliberately left alone: infra.mk:89 (z890's declared sub-fix), WS1/WS3/WS4. Recommends Mavis-5090 for WS4-B, since the "rooms pull portals" model is their open OpenRoom slice-2 claim. The handoff doc also carries a WS3-relevant finding: AGNOTE4482PHI.t1.md was damaged three times in a row by stale-base merges (#2437 markers, #2450 deleting six entries, a corrupted duplicate). A deletion is a valid diff, so nothing catches it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(ws2): retract hf-mcp-server from the submodule list, add the bind-mount class Two corrections to the handoff doc, made before the enumeration propagates. RETRACTION. An earlier revision added hf-mcp-server.yml to the sibling-submodule build list. Wrong. Its context is ../../pmoves/services/hf-mcp-server — a two-level relative path back INTO pmoves/services/, i.e. a first-party service. My matcher keyed on a leading `../`, which is not sufficient: the first path segment has to be checked against .gitmodules. Corrected list is 7 registered submodules / 8 services, which is z890's original number plus n8n. This is the same class of error as the "13 of 15" figure it was meant to fix — pattern- matching a path shape instead of resolving it. ADDITION. The enumeration covers build contexts only, and those are the less dangerous half. Five BIND-MOUNT sources also come from submodules (PMOVES-supabase x4, PMOVES-n8n x1). A missing build context fails loudly; a missing bind source does not — Docker CREATES it as a directory, so a file mount silently becomes a directory mount and the container then fails on its own config. That is the class that took services down on this node, and it is the reason item 4 is a runbook rather than a code fix. Also records item 3's outcome: the two claude-pmoves.sh were never duplicates. One selects an agent and loads nothing; the other loads env + the MCP roster and selects no agent. Each ends in its own `exec claude`, so they are mutually exclusive, and `make -C pmoves claude-pmoves` took the path with no creds. Picking one — the item as written — would have deleted a working capability either way. Fixed by delegation in #2484. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(ws2): add claim TTL, split evidence provenance, correct the CI-blindness claim Review pass on the claim + handoff. All six findings were valid; none were cosmetic. TTL. The claim had no expiry, so an abandoned branch would reserve these items indefinitely with no way for another node to tell when reclaiming is safe. Added: TTL 72h, expires 2026-08-11T13:00:00Z. OWNERSHIP COUNT. The entry said "five items claimed" while the body enumerated items 2-5 and the next paragraph assigned item 1 to z890 — ambiguous in exactly the file that exists to prevent collisions. Now states WS2 has five items and 4090 reserves FOUR of them, with item 1 named as z890's. PROVENANCE. "Everything re-verified via git show against origin/main" was not true of the whole document: it also carries GitHub Actions run results and node runtime observations, neither of which git show can produce. Now split three ways — repository content via git show, CI behavior via gh api on run records, node runtime state via docker inspect / git submodule status on THIS node only (single-node observation, not a fleet claim). CI-BLINDNESS CLAIM WAS WRONG. The doc said CI cannot catch the submodule gap because workflows check out with `submodules: recursive`. They do not check out submodules at all (validate-dockerfile-paths-ratchet.yml:54, validate-composes-ratchet.yml:41). They pass because validate_dockerfile_paths.py explicitly excludes sibling-submodule targets — "external repos the ratchet can't statically check" — and because validate-composes never inspects bind sources. A known, accepted blind spot rather than an accidental one. That is a better argument for the runbook, not a worse one, and it is now the one the doc makes. TRIGGER ROW. Correction 3 said `issue_comment` and `push` were both correct and only `pull_request_review` was wrong. `push` resolves from the PUSHED ref, so that was half-right; my first fix left the other half standing. Now a three-row table with the two halves' provenance distinguished — the pull_request_review correction is empirical from runs 31257145963 / 31257247543, the push correction is Actions semantics from review and is stated as behavior rather than as something measured here. Plus: item 3's outcome recorded (the two claude-pmoves.sh were never duplicates, fixed by delegation in #2484), and MD040 language identifiers on three fenced blocks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 8, 2026
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 9, 2026
…reign RELEASE lines (#2498) * docs(agnote): WS2 RELEASE + lane sweep — evidence for owners, no foreign RELEASE lines Two entries. RELEASE — WS2 (z890's coordination plan) is complete inside its 72h TTL. Eight PRs merged: #2482 claim+handoff+corrections, #2483 ci-expedition skill, #2484 claude-pmoves delegation, #2485 submodule gap runbook, #2486 up-* inventory, #2488 validate-command-anchors, #2494 first-contact + guard routing table, #2495 Danger Room handoff to SPARK. pmoves/mk/infra.mk untouched throughout — z890's #2480, no collision. The entry records what the audit found BEYOND its enumerated items, because that is the reusable part: a gate can advertise coverage it does not have (three separate instances, each caught by review rather than by me); the always-loaded orientation file misdirects first contact; the guard's own routing table has two dead roads; and patterns.yaml is the pattern worth generalizing while pre-tool.sh duplicates 5 of its entries minus the affordance. It also records four corrections to my own prior work — the wrong 13-of-15 figure, the retracted hf-mcp-server entry, the dangerous first up-* retire list, and the yt-cookies pair that was never a duplicate. A closeout that only lists wins is not a closeout. NOTE — lane sweep. 115 CLAIM against 119 RELEASE. Four Mavis lanes verified shipped and missing only a RELEASE (harness v0 #2437/#2443/#2450, multi-fork follow-ups #2477, OpenRoom slice 2, creative-pipeline v0). Four older lanes still open with no PR cited and nothing found merged, now 8-10 days. Mine that are correctly still open: #2446 draft, #2468 held for review, and the SPARK handoff awaiting its CLAIM. ZERO RELEASE lines written on another agent's behalf — verified in the diff. Those lanes are Mavis's to close under Village Rule; this records evidence so they can close from it rather than from memory. Kept distinct from the KIMI-SPARK / CRUSH stale claims, which need a release OR re-claim — different category, and conflating them would make the ping inaccurate. Verified: make -C pmoves validate-command-anchors passes. Note for follow-up: dogfooding this entry surfaced a real false-positive generator in MAKE_CITE_RE — `-C \S+` swallows a closing backtick, so prose that backticks "make -C pmoves" alone captures the following word as a target. Fixed separately, not folded in here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(agnote): state the counting method, and stop treating merge as acceptance Three review findings, all correct, all mine. 1. THE TOTALS WERE NOT REPRODUCIBLE. I published "115 CLAIM against 119 RELEASE" with no method attached. Recounting three ways on the same file: anchored bullet rows 115 / 119 <- what I published token anywhere in text 284 / 221 (prose mentions) timestamped, no anchor 116 / 119 and the 2026-08-07 sweep reported 121 / 115 on a fourth. None of these is wrong; a bare number with no pattern is. The entry now states the exact regex, lists what the other methods give, and says to treat the ratio as a rough signal rather than a metric — the per-lane table is the checkable part. 2. MERGE IS NOT RUNTIME ACCEPTANCE. I listed OpenRoom slice 2 under "verified shipped, missing only a RELEASE" on the strength of #2437 merging. That lane was claimed against six handoff priorities with room-level acceptance, and #2437 is scaffold plus iframe wiring. Merging it does not demonstrate the rooms render. 3. Same for line 1723: it covers three deliverables including fork-side consumers, and #2477 merging in PMOVES.AI says nothing about whether the fork consumers landed. Both are now "merged, acceptance unverified" rather than ready-to-release, with the reasoning stated so the owner closes from runtime evidence instead of from my table. This is precisely the error the register exists to prevent, made by the sweep that exists to catch it — which is worth leaving visible rather than quietly correcting. Every gate I shipped this week was weaker than advertised until something proved it could say no; this one was a bookkeeping claim that had not been asked to reproduce itself. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Mavis creative-pipeline v0: sketch -> render -> skin foundation
The Mavis creative pipeline v0 slice lands the integration foundation that turns Cataclysm Studios sketch archive (G:\My Drive\CataclysmstudiosInc\Pictures) + 82 SoundCloud tracks into the production substrate for the music video + AI comic + CHIT viz pipeline.
The render itself happens later (operator runs the Aitrepreneur installer on an H3-capable host, Mavis submits the prompt), but the foundation is now in
pmoves/tools/, self-explanatory, cross-agent pickup-ready, and respects the "sketch is the finished piece" framing.What's in this PR
pmoves/tools/comfyui/install/- 3 Aitrepreneur MiniMax H3 ULTRA installers (RunPod + Windows portable + Windows safe), verbatim from the operator's localDownloads/SEAP/with full attributionpmoves/tools/comfyui/workflows/- 2 H3 ULTRA ComfyUI workflow JSONs (standard + turbo-LoRA), default is turbo (4-step, ~30-60s render at 5s 720p on RTX 4090)pmoves/tools/comfyui_client.py- synchronous Python HTTP wrapper for the ComfyUI REST API (submit, wait, download). Env-driven. 12/12 tests passpmoves/tools/pinokio_launch.sh- shell wrapper forpinokio start <app>+ port-readiness polling. Cross-platform (Python3 fallback for Git Bash). 8/8 tests passpmoves/tools/render_skin.py- the pipeline glue. Sketch + prompt -> patched workflow -> ComfyUI render ->theme.skin/v1JSON. 14/14 tests passpmoves/tools/comfyui/README.md- high-level map for future agents picking this upAcceptance criteria (5/5 met)
theme.skinJSONTests (34/34 pass, no ComfyUI host required)
pmoves/tools/tests/test_comfyui_client.py- 12 testspmoves/tools/tests/test_pinokio_launch.sh- 8 testspmoves/tools/tests/test_render_skin.py- 14 testsThe "sketch is the finished piece" loop
The operator's 2023-11-03 6-eye third-eye horned-helmet character (cyber.png) becomes a Pillar 4 encoding pillar skin in 3 commands:
pinokio_launch.sh comfyui --port 8188(launch the ComfyUI host)python -m pmoves.tools.render_skin "G:\My Drive\CataclysmstudiosInc\Pictures\cyber.png" "Pillar 4 encoding visual, third eye, 6-eye motif" --output pmoves/design/skins/pillar4-encoding.json(submit + wait + download)The same loop works for the 82 SoundCloud tracks, the IDW/Transformers-style comic panels, and the CHIT tour pillars.
What this PR does NOT do (left for follow-up)
cyber.pngrender - needs a ComfyUI host with H3. Operator runs the installer.CLAIM
Mavis::MAVIS-CREATIVE-PIPELINE-V0-CLAIM::2026-08-06inpmoves/docs/AGENTS/AGNOTE4482PHI.t1.mdTrail entry
graphiti:mavis phase:creative-pipeline-v0indocs/AGENT_TRAIL.mdLEARNINGS
pmoves/tools/LEARNINGS/creative-pipeline-v0_LEARNINGS.md- 5-class taxonomy (legit/already-fixed/owner/out-of-scope/pre-existing) + 4-bucket learning signal (missed-signal/fix-pattern/wrong-suggestion/already-addressed) for the post-merge review cycle.CHIT trail unsigned-local
No
CHIT_PASSPHRASEloaded in this Mavis session per the standing operator convention.Summary by CodeRabbit
New Features
Documentation
Tests