From 63772412b4640805d8ba1fbdf1412c514c7834fc Mon Sep 17 00:00:00 2001 From: wantsong Date: Tue, 7 Jul 2026 18:11:45 +0800 Subject: [PATCH] docs: add remotion workflow rules --- .gitignore | 14 +++ AGENTS.md | 38 +++++- PROJECTS.md | 4 +- README.md | 19 ++- VIDEO_WORKBENCH.md | 69 ++++++++--- docs/context-handoff.md | 26 ++-- docs/workflows/project-lifecycle.md | 6 +- docs/workflows/slide-task-orchestration.md | 132 ++++++++++++++++++++- docs/workflows/slide-task-templates.md | 104 +++++++++++++++- 9 files changed, 370 insertions(+), 42 deletions(-) diff --git a/.gitignore b/.gitignore index 34464f6..bab76ff 100644 --- a/.gitignore +++ b/.gitignore @@ -23,3 +23,17 @@ projects/**/renders/** projects/**/exports/** projects/**/videos/** projects/**/archive/** + +# Remotion / Node project generated files +projects/**/remotion/node_modules/ +projects/**/remotion/.cache/ +projects/**/remotion/.turbo/ +projects/**/remotion/out/ +projects/**/remotion/dist/ +projects/**/remotion/build/ +projects/**/remotion/.next/ +projects/**/remotion/*.mp4 +projects/**/remotion/*.mov +projects/**/remotion/*.webm +projects/**/remotion/*.avi +projects/**/remotion/*.mkv diff --git a/AGENTS.md b/AGENTS.md index 5197748..a69bd4f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -84,9 +84,42 @@ For every project-bound image prompt document: Project-bound image generation must remain approval-gated: save the prompt/spec first, wait for user approval, then execute generation only when explicitly requested. A task-level user instruction that records the running mode and slide scope counts as explicit generation approval for that task scope. If the task mode is `prompt only`, do not generate images. +## Remotion Workflow + +Use this workflow when accepted planning material, the user, or the active task says the video should be implemented in Remotion, or when Codex writes or edits Remotion code. + +Remotion planning from `强哥的策划导演3.0` is a planning source, not an execution package. GPT may provide Remotion adaptation judgments, a Remotion style-system anchor, storyboard-to-component mapping, and a Remotion Implementation Brief. GPT must not be treated as the source for final code paths, dependency commands, render commands, or complete Remotion source code. + +Default local source root: + +```text +projects//remotion/ +``` + +Use this path for one-off project-specific Remotion source. Reusable products, reusable templates, deployable systems, or business software belong in the relevant `work-projects` repository instead of Video Workbench unless the user explicitly keeps them local for a prototype. + +Default Remotion deliverable: + +```text +source code + renderable MP4 +``` + +For project-bound Remotion work: + +- use worker profile `remotion-video-production`; +- read `C:\Users\wangq\.agents\skills\remotion\SKILL.md` before writing or editing Remotion code; +- before visual scenes, layouts, motion graphics, or text-heavy Remotion screens, also read the Remotion Skill's relevant rule files, starting with `rules/video-layout.md`; +- load narrower Remotion Skill rule files when the task involves captions, audio, transitions, charts, maps, 3D, effects, timing, images, fonts, or parameterized videos; +- keep Remotion assets referenced by source code under `projects//remotion/public/` unless the project has a better local convention; +- place rendered MP4s or render tests under `projects//renders/`, `projects//exports/`, or another path recorded in `execution-plan.md`; +- keep generated render outputs out of Git by default; record their paths, status, and hashes when useful for continuation; +- run narrow code/render checks for Remotion work, such as typecheck/build when available and `npx remotion still` or an explicit render command for the target composition. These checks are part of code output validation, not optional image review. + +The user has given standing task-level permission for first and future Remotion tests to use `npx create-video`, npm dependency installation, and Remotion render commands when the active task needs them. Tooling may still require sandbox/network escalation approval at command time. + ## Slide Task Workflow -For long slide / video production work, use the local slide task orchestration workflow: +For long slide / video production work, including Remotion scene or section production, use the local slide task orchestration workflow: ```text docs/workflows/slide-task-orchestration.md @@ -147,6 +180,7 @@ Rules: - Production-light child sessions write per-slide briefs, prompts, images, and compact handoff directly; they may handle at most 8 ordinary production slides by default. Reduce to 1-3 slides for identity-heavy, repair-heavy, core-risk, or context-expensive scopes. - Test/audit child sessions may launch slide agents; a slide agent handles exactly 1 slide per invocation. - The default worker profile for current MV / video work is `video-slide-production`. +- Use `remotion-video-production` when the accepted plan calls for Remotion implementation, Remotion scene/component production, or a renderable MP4 from React/TypeScript source. - Reserved future profile `ppt-page-production` may use `docs/cases/`, but must be designed when the first real PPT task needs it. - For cover pages, PPT pages, science-video pages, title cards, explainer pages, or any slide that needs later human layout / typography / post-production, add a separate `sNN-vN-design.md` before `brief`. `design` is for the user and records visual concept, layout, text content, typography/color guidance, post-production notes, constraints, and references. `brief` remains the execution card for Codex / image generation and must not absorb human-facing design or post-production notes. - `sNN-vN-design.md` is Chinese by default. If an English design companion is needed, write `sNN-vN-design-en.md` beside it; the English file supplements but does not replace the default Chinese design. @@ -157,7 +191,9 @@ Rules: - Character continuity must use `visual-system/characters/character-reference-registry.md` and active character image references. - Visible character identity cannot be generated from text-only prompts when identity matters. - Slide prompts must use the `gpt-image-2` Skill Advisor / host-native workflow. +- Remotion code must use the installed Remotion Skill workflow and should not use `gpt-image-2` unless the Remotion project separately needs generated still assets. - In `slides/sNN/`, keep Markdown control/script artifacts in Git, but treat generated images, audio, and video as asset-layer files that are ignored by default and recorded by path/hash/status in control files. +- In `projects//remotion/`, keep source code, package files, and source assets in Git by default; keep `node_modules`, caches, build outputs, and rendered media ignored by default. - Assembled `.pptx` / `.pdf` files under project `slides/` are generated deliverables. Do not commit them unless the user explicitly promotes a named file as source-authority material. - Project `archive/` directories are for discarded images and discarded documents by default. Do not add them to Git unless the user explicitly promotes a specific archived item back into `intake/`, `visual-system/`, or another source-authority location. - New slide-task execution must append the next unused `sNN-vN-*` version and must not overwrite existing slide artifacts unless the user explicitly authorizes an overwrite repair for named files. diff --git a/PROJECTS.md b/PROJECTS.md index 779432f..01a242f 100644 --- a/PROJECTS.md +++ b/PROJECTS.md @@ -15,6 +15,7 @@ It turns accepted planning material and deep source references into public-facin - video outlines; - storyboard logic; - shot-level production files; +- project-specific Remotion source and render receipts; - voiceover scripts; - image prompts; - asset manifests; @@ -31,7 +32,7 @@ It does not own upstream deep creation, canonical agents, reusable automation so | `writing-workbench` | Sibling workspace for deep article production | completed or sufficiently stable article projects when the user chooses to make video content | no default output | | `ccpe-system` | Supplier of local work agents, runtime rules, model cards, and governed cognitive assets | the external `Interface.md`, the consumer setup contract, and task-specific canonical artifacts only when routed by the setup/registry | capability requests under `requirements/ccpe/` | | `skills-vault` | Supplier of deterministic automation tools | file processors, batch utilities, asset tools, export tools, installable automation skills | capability requests under `requirements/skills-vault/` | -| `work-projects` | Separate software/customer project workspace | no default input | production system requirements if this video workflow is later packaged as deployable software | +| `work-projects` | Separate software/customer project workspace | no default input | production system requirements if this video workflow is later packaged as deployable software or a reusable Remotion product/template | ## Boundary Rules @@ -40,6 +41,7 @@ It does not own upstream deep creation, canonical agents, reusable automation so - Long-term sources, finished essays, model documents, and open-ended discussion memory belong in `knowledge-vault`. - Canonical local-work agents, prompts, runtimes, model cards, and invocation protocols belong in `ccpe-system`; Video Workbench starts from `ccpe-system\Interface.md`, not from hardcoded internal CCPE artifact paths. - Deterministic reusable automation implementation source belongs in `skills-vault`. +- One-off project-specific Remotion source belongs under `projects//remotion/`; reusable Remotion products, reusable templates, deployable systems, and customer/business software belong in `work-projects`. - If the video workflow is later packaged as a deployable system, production/business agent implementation belongs in the relevant `work-projects` repository, not in this local workbench. - Missing capabilities are requested through `requirements/`, not implemented ad hoc inside this repository. diff --git a/README.md b/README.md index a7719f1..426ec08 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,15 @@ # Video Workbench -Video Workbench is the local execution workspace for dimensional video and slide-style output. It receives GPT V2 planning Markdown from the user, keeps lightweight project records, and produces local execution plans, visual-system assets, prompts, images, narration audio, slide/page files, and handoff notes. +Video Workbench is the local execution workspace for dimensional video, Remotion, and slide-style output. It receives GPT planning Markdown from the user, keeps lightweight project records, and produces local execution plans, visual-system assets, prompts, images, Remotion source projects, narration audio, renderable video files, slide/page files, and handoff notes. It is a sibling of Writing Workbench, not a subfolder of it. ## Working Model ```text -GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons +GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons, Remotion planning briefs User = decisions, source material, accepted planning files -Video Workbench = stage 6+ execution planning, Prompt Advisor work, visual-system materialization, generated assets, handoff +Video Workbench = stage 6+ execution planning, Prompt Advisor work, Remotion implementation, visual-system materialization, generated assets, handoff CCPE System = local work agents, runtimes, model cards, interfaces Skills Vault = reusable automation skills and deterministic tools ``` @@ -28,6 +28,10 @@ projects/ visual-system.md refs/ iterations/ + remotion/ + package.json + src/ + public/ slides/ slides.md s01/ @@ -43,10 +47,11 @@ ccpe-consumption/ ``` - `projects/` is the only project entry point. Project status and series membership are recorded inside project files, not by moving directories. -- `projects//intake/` holds user-provided GPT V2 stage 0-5 Markdown, source notes, references, and other accepted inputs. +- `projects//intake/` holds user-provided GPT stage 0-5 Markdown, source notes, references, and other accepted inputs. - `projects//project.md` is a Codex-maintained project note and file map. It should link to content in `intake/`, not duplicate it. - `projects//execution-plan.md` is the project-level execution control file for visual work. It records the current strategy, batch, round, and next decision instead of duplicating the project map. - `projects//visual-system/visual-system.md` records the current accepted visual system, materialization targets, iteration log, failure attribution, and next action. Reference images and iteration artifacts stay under `refs/` and `iterations/`. +- `projects//remotion/` is the default source root for one-off project-specific Remotion videos. Keep source code, package files, and source assets there; keep generated renders, caches, and dependencies out of Git by default. - `projects//slides/` is the working area for slide, page, or shot execution. Each `sNN/` folder keeps that unit's prompts, narration, generated images, audio, and local notes together. Files inside `sNN/` must carry the `sNN` prefix, and iteration files use `sNN-vN-type.ext`, such as `s03-v1-prompt.md`. - `handoff/` is for repo-level, cross-project, or context-window handoff notes. - `docs/cases/` is the Codex-side local case-pattern library extracted from old real GPT cases. It preserves execution patterns, not old prompts, JSON packages, paths, or global text-rendering rules. @@ -58,8 +63,10 @@ Series indexes can be added later under `projects/_series/` when a real series n ## Boundaries - Manual editing and publishing remain human-controlled unless explicitly automated later. -- Video Workbench does not default to full video editing, image-to-video generation, or platform publishing. -- Codex does not ask GPT V2 for final image prompts, Codex JSON, output paths, task lists, or image generation parameters. +- Video Workbench does not default to full manual video editing, image-to-video generation, or platform publishing. +- Codex does not ask GPT for final image prompts, Codex JSON, output paths, task lists, dependency commands, render commands, or complete Remotion source code. +- For Remotion videos, accepted GPT planning can supply adaptation judgment, a style-system anchor, storyboard-to-component mapping, and a Remotion Implementation Brief. Codex owns the local source layout, implementation, dependency commands, render commands, and validation. +- The default Remotion deliverable is source code plus a renderable MP4. The user has standing task-level permission for `npx create-video`, npm dependency installation, and Remotion render commands when a Remotion task needs them; sandbox or network approvals may still be requested at command time. - `makeup-still/` is not a recommended project directory. Character, scene, template, diagram, and background anchors belong under `visual-system/` when needed. - `tmp/` is deprecated. New reusable or reviewable investigation material belongs under `investigations/`. - Missing CCPE assets should be requested under `requirements/ccpe/`. diff --git a/VIDEO_WORKBENCH.md b/VIDEO_WORKBENCH.md index 5746ef0..0a8914f 100644 --- a/VIDEO_WORKBENCH.md +++ b/VIDEO_WORKBENCH.md @@ -2,19 +2,21 @@ ## 1. Workspace Identity -This project is the local execution workspace for dimensional video and slide-style output. +This project is the local execution workspace for dimensional video, Remotion, and slide-style output. -It turns accepted GPT V2 planning Markdown and user-provided sources into project notes, local execution plans, visual-system assets, slide/page execution folders, generated assets, and compact handoff material. It is optimized for practical continuation and production throughput, not heavy governance. +It turns accepted GPT planning Markdown and user-provided sources into project notes, local execution plans, visual-system assets, slide/page execution folders, Remotion source projects, generated assets, renderable video files, and compact handoff material. It is optimized for practical continuation and production throughput, not heavy governance. ## 2. Collaboration Roles ```text -GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons +GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons, Remotion planning briefs User = decisions, accepted inputs, source/reference material -Codex = stage 6+ execution planning, Prompt Advisor work, visual-system materialization, iteration, local assets +Codex = stage 6+ execution planning, Prompt Advisor work, Remotion implementation, visual-system materialization, iteration, local assets ``` -GPT V2 does not provide final image prompts, Codex JSON, output paths, task lists, or image generation parameters. Codex should not request those from GPT as missing inputs. +GPT does not provide final image prompts, Codex JSON, output paths, task lists, dependency commands, render commands, complete Remotion source code, or image generation parameters. Codex should not request those from GPT as missing inputs. + +For Remotion videos, accepted planning from `强哥的策划导演3.0` may provide Remotion adaptation judgment, a Remotion style-system anchor, storyboard-to-component mapping, and a Remotion Implementation Brief. The brief is a planning source, not a Codex execution package. Codex should not rewrite GPT planning into duplicate project content. The accepted planning files belong in the project `intake/` directory, and Codex turns them into local execution decisions in `execution-plan.md`. @@ -32,6 +34,10 @@ projects/ visual-system.md refs/ iterations/ + remotion/ + package.json + src/ + public/ slides/ slides.md s01/ @@ -55,8 +61,10 @@ If a series needs more structure, create `projects/_series/` when the first real - lifecycle phase from `docs/workflows/project-lifecycle.md`; - workflow phase: new projects default to `test/audit`; switch to `production-light` only after explicit user authorization; - medium type; +- worker profile, such as `video-slide-production`, `remotion-video-production`, or a future profile; - source and reference links; -- which `intake/` files are GPT V2 planning Markdown, source notes, reference notes, or background notes; +- which `intake/` files are GPT planning Markdown, source notes, reference notes, or background notes; +- Remotion source root when applicable, defaulting to `projects//remotion/`; - current execution focus; - key local execution files; - next action. @@ -81,8 +89,10 @@ This is a living Codex-maintained execution control file. It records: - the current medium branch; - the current lifecycle phase when it affects execution; +- the active worker profile; - the current execution focus; - which visual-system assets need materialization; +- for Remotion projects, source root, package manager state, composition IDs, render target, render output path, and validation commands; - the current small-batch iteration strategy; - which `sNN` units are in the active batch; - the current round; @@ -94,9 +104,10 @@ It should not repeat the project ID, full intake file index, or project map from `projects//intake/` holds material provided or accepted by the user: -- GPT V2 stage 0-5 planning Markdown; +- GPT stage 0-5 planning Markdown; - outlines; - storyboards, page skeletons, or shot skeletons; +- Remotion adaptation judgments, Remotion style-system anchors, Remotion storyboards, storyboard-to-component mappings, and Remotion Implementation Briefs; - background notes; - reference images, audio notes, or source pointers. @@ -171,10 +182,13 @@ visual-system/scenes/ visual-system/templates/ visual-system/diagrams/ visual-system/backgrounds/ +visual-system/remotion/ ``` Do not create a separate `makeup-still/` directory. Character anchors and identity references belong under `visual-system/`. +For Remotion projects, record the accepted Remotion style-system anchor under `visual-system/remotion/` or in `visual-system/visual-system.md` if the project is small. It should cover background systems, color and type hierarchy, component style, information density, animation language, transition motifs, chart/flow/formula handling, subtitle strategy, and reusable component suggestions. This is source authority for the Remotion implementation; it is not React/TypeScript code. + After a character anchor stage is accepted, clean the character workspace before scene generation: - keep only current usable character references under `visual-system/characters/`; @@ -186,11 +200,11 @@ For identity-critical shots, prompt specs must choose the person reference from ## 8. Slides And Shots -Use `slides/` as the execution unit area for both video shots and PPT-style pages. +Use `slides/` as the execution unit area for video shots, PPT-style pages, Remotion scenes, and Remotion sections. -`projects//slides/slides.md` is the unit execution fact table. It records each page or shot's source, batch, current prompt version, current image version, review state, acceptance state, and notes. Project-level iteration strategy belongs in `execution-plan.md`. +`projects//slides/slides.md` is the unit execution fact table. It records each page, shot, Remotion scene, or Remotion section's source, batch, current prompt/spec version, current image/render/component status, review state, acceptance state, and notes. Project-level iteration strategy belongs in `execution-plan.md`. -Each `slides/sNN/` folder keeps one slide, page, or shot together: +Each `slides/sNN/` folder keeps one slide, page, shot, Remotion scene, or Remotion section together: ```text slides/ @@ -203,6 +217,8 @@ slides/ s01-visual-brief.md s01-v1-prompt.md s01-v1-image.png + s01-v1-remotion-spec.md + s01-v1-render-check.md s01-v1-review.md # optional; test/audit or explicit review only s01-v2-prompt.md s01-v2-image.png @@ -211,11 +227,13 @@ slides/ All files inside `sNN/` must carry the `sNN` prefix. Iteration files use `sNN-vN-type.ext`, so files from the same version sort together. -`design` is a human-facing design specification, not an image-generation execution card. Use `sNN-vN-design.md` for cover pages, PPT pages, science-video pages, title cards, explainers, and any slide that needs later human layout, typography, text placement, or post-production. It records the design concept, intended text, placement, typography/color guidance, constraints, references, and post-production notes. `brief` stays compact and execution-facing for Codex / image generation. +`design` is a human-facing design specification, not an image-generation execution card. Use `sNN-vN-design.md` for cover pages, PPT pages, science-video pages, title cards, explainers, Remotion scenes with meaningful typography/layout choices, and any slide that needs later human layout, typography, text placement, or post-production. It records the design concept, intended text, placement, typography/color guidance, constraints, references, and post-production notes. `brief` stays compact and execution-facing for Codex / image generation or Remotion implementation. `sNN-vN-design.md` is Chinese by default. If an English design companion is needed, write `sNN-vN-design-en.md` beside it. The English companion is optional and never replaces the Chinese default. -For design-gated slides, write `design` first and wait for user confirmation before writing `brief`, `prompt`, or generating images, unless the user explicitly authorizes the whole chain. Ordinary MV shot production may skip `design` and continue directly with `brief -> prompt -> image`. +For design-gated slides, write `design` first and wait for user confirmation before writing `brief`, `prompt`, Remotion specs, or generating/rendering outputs, unless the user explicitly authorizes the whole chain. Ordinary MV shot production may skip `design` and continue directly with `brief -> prompt -> image`. + +For Remotion work, `slides/sNN/` holds scene/section intent and checks. React/TypeScript source code lives under `projects//remotion/`. Do not store normal component source as append-only `sNN-vN-*` Markdown; use Git history for code changes and use `slides/sNN/` for the scene spec, component mapping, and render evidence. New task execution must append a new slide version instead of overwriting an existing one. Resolve the next unused `vN` from existing `sNN-v*-*` files in the slide folder, and treat incomplete or superseded earlier versions as historical evidence rather than paths to reuse. @@ -247,17 +265,18 @@ This file records the target scope, completed units, active child session, next Roles: - Main session: receives user instructions, defines worker profile / running mode / slide scope, starts child sessions, records the parent callback target, and reads handoffs after callback. -- Child session: reads shared context and handles the assigned package. In `production-light`, it directly writes briefs, prompts, generated images, `slides/slides.md` updates, and a compact handoff before callback. +- Child session: reads shared context and handles the assigned package. In `production-light`, it directly writes briefs, prompts/specs, generated images or Remotion code/render outputs, `slides/slides.md` updates, and a compact handoff before callback. - Slide agent: optional worker for `test/audit`, explicit review, repair, exception handling, or intentionally isolated slide work. It handles exactly one slide when used. Operating lines: - `test/audit`: early project setup, core-shot proving, mechanism debugging, or failure investigation. Richer handoffs, ledgers, local review files, Agent workers, and parent inspection are allowed. -- `production-light`: normal production after core shots have reached the expected look and the user authorizes the switch in `project.md`. Keep the content line (`brief`, `prompt`, generated image, `slides/slides.md`) and compact recovery handoff; omit routine review, Agent workers, packet/return files, and audit records. +- `production-light`: normal production after core shots or the core Remotion route have reached the expected look and the user authorizes the switch in `project.md`. Keep the content line (`brief`, `prompt/spec`, generated image or Remotion source/render, `slides/slides.md`) and compact recovery handoff; omit routine review, Agent workers, packet/return files, and audit records. Defaults: - Worker profile for current video / MV work: `video-slide-production`. +- Worker profile for Remotion videos: `remotion-video-production`. - Design-gated slides: cover, PPT, science-video, title, explainer, and post-production-heavy pages require `sNN-vN-design.md` before `brief`. - Child session capacity: at most 8 ordinary production slides; reduce to 1-3 for identity-heavy, repair-heavy, core-risk, or context-expensive scopes. - Production-light topology: main session -> child session directly. @@ -274,8 +293,11 @@ The user controls task running mode: - `prompt only`: create briefs and prompts; do not generate images. - `prompt and generate`: create briefs and prompts, then generate images for the task's recorded slide scope. +- `remotion plan only`: create Remotion execution specs and mappings; do not write source code. +- `remotion implement`: write or edit Remotion source and run narrow source checks; do not render final MP4 unless the task also authorizes rendering. +- `remotion render`: write or edit source as needed, run narrow source checks, and render the target MP4. -Task-level generation instructions count as user approval for the named scope and mode. In production-light, generated images are recorded as production-pass outputs without per-image user review or routine final verification; the user can request an append-only retry later if a result is not usable. Core, repair, identity-heavy, or otherwise high-risk slides may still pause if the task plan says they require sampling or explicit review. +Task-level generation or Remotion render instructions count as user approval for the named scope and mode. In production-light, generated images are recorded as production-pass outputs without per-image user review or routine final verification; the user can request an append-only retry later if a result is not usable. Remotion source/render work is code work and must run the task's narrow checks before closeout. Core, repair, identity-heavy, otherwise high-risk slides, or uncertain Remotion animation systems may still pause if the task plan says they require sampling or explicit review. For unattended production, the parent session repeats the callback loop from `docs/workflows/project-lifecycle.md`: update `production-run-status.md`, dispatch one child session, wait for callback, reload the minimal project/task state, then dispatch the next package if no stop condition is present. Exact parent context/token usage is not required for continuation because Codex may auto-compress the parent session; file-backed state is the authority. @@ -286,6 +308,18 @@ Visual-system rules: - Character continuity must use `visual-system/characters/character-reference-registry.md` and active character reference images. - Visible character identity cannot be generated from text-only prompts when identity matters. - Slide prompts must use the `gpt-image-2` Skill Advisor / host-native workflow. +- Remotion implementation must use the installed Remotion Skill before code edits. Read `C:\Users\wangq\.agents\skills\remotion\SKILL.md`, then read relevant `rules/*.md` files for the task area. + +Remotion project rules: + +- Default source root: `projects//remotion/`. +- Default deliverable: source code plus renderable MP4. +- One-off project-specific Remotion source belongs in Video Workbench. Reusable products, reusable templates, deployable systems, and business software belong in `work-projects` unless the user explicitly keeps a prototype local. +- The user has standing task-level permission for Remotion tasks to use `npx create-video`, npm dependency installation, and Remotion render commands when needed. Normal sandbox/network approval requests still apply at command time. +- Keep source code, package files, and source assets in Git by default. Keep `node_modules`, caches, build outputs, and rendered media ignored by default. +- Use `projects//remotion/public/` for assets referenced with Remotion `staticFile()` unless a task records a different local convention. +- Use `projects//renders/` or `projects//exports/` for MP4 outputs unless the task records another render path. +- For Remotion code, normal source edits are not append-only `sNN-vN-*` artifacts; use Git history and code review. Append-only rules still apply to Markdown control artifacts, scene specs, render checks, and generated media receipts. Review rules: @@ -293,6 +327,7 @@ Review rules: - Test/audit review defaults to local-only unless the task says otherwise. - Do not call Minimax MCP or other external vision/review services unless the user explicitly authorizes that task. - Generated production slides can be tracked in `tasks//task-log.md` and `slides/slides.md` instead of a full per-slide review. +- Remotion render checks are source/render validation, not external visual review. Record the command, composition ID, output path, and result in the compact handoff or a `sNN-vN-render-check.md` file when the check is scene-specific. ## 9. Investigations @@ -317,11 +352,11 @@ Adjust only when the user specifies a different narration speed. Image and audio generation can be automated when available skills or APIs are appropriate. -Video generation from images remains manual or semi-manual for now because output reliability varies. +Video generation from images remains manual or semi-manual for now because output reliability varies. Remotion is a separate programmatic video path: use it when the accepted plan calls for React/TypeScript animation, scene composition, captions, charts, diagrams, or renderable MP4 output from source code. Editing and publishing are human-controlled unless explicitly automated later. -Codex is the default prompt owner for final image prompts in this workspace, but final prompts must be produced through the `gpt-image-2` Skill workflow rather than direct freehand drafting. GPT V2 planning Markdown remains a source specification, not a final prompt. +Codex is the default prompt owner for final image prompts in this workspace, but final prompts must be produced through the `gpt-image-2` Skill workflow rather than direct freehand drafting. GPT planning Markdown remains a source specification, not a final prompt. For project-bound image prompts, Codex must: diff --git a/docs/context-handoff.md b/docs/context-handoff.md index 2be93e4..9801ed7 100644 --- a/docs/context-handoff.md +++ b/docs/context-handoff.md @@ -14,19 +14,21 @@ Skills Vault = reusable automation skill supplier Video Workbench is a sibling of Writing Workbench. It should not be folded into article production because the target output, rhythm, assets, and evaluation criteria are different. -Video Workbench keeps local project notes, execution outputs, and handoff records. It does not own canonical prompts, agent definitions, reusable automation source code, or production/business agent implementation for deployable systems. +Video Workbench keeps local project notes, execution outputs, Remotion source for one-off project videos, and handoff records. It does not own canonical prompts, agent definitions, reusable automation source code, reusable Remotion products/templates, or production/business agent implementation for deployable systems. ## Collaboration Contract ```text -GPT / ChatGPT = stage 0-5 planning Markdown, visual-system design, page/shot skeletons +GPT / ChatGPT = stage 0-5 planning Markdown, visual-system design, page/shot skeletons, Remotion planning briefs User = decisions and accepted input placement -Codex = stage 6+ execution planning, Prompt Advisor work, visual-system materialization, iteration, generated assets +Codex = stage 6+ execution planning, Prompt Advisor work, Remotion implementation, visual-system materialization, iteration, generated assets ``` -Most planning files should come from GPT V2 output accepted by the user and placed in `projects//intake/`. Codex-maintained files should be local execution aids and execution records. +Most planning files should come from GPT output accepted by the user and placed in `projects//intake/`. Codex-maintained files should be local execution aids and execution records. -Codex should not ask GPT V2 for final image prompts, Codex JSON, output paths, task lists, or image generation parameters. GPT V2 planning Markdown is a source specification, not an execution command. +Codex should not ask GPT for final image prompts, Codex JSON, output paths, task lists, dependency commands, render commands, complete Remotion source code, or image generation parameters. GPT planning Markdown is a source specification, not an execution command. + +For Remotion videos, accepted planning from `强哥的策划导演3.0` can provide Remotion adaptation judgment, a Remotion style-system anchor, storyboard-to-component mapping, and a Remotion Implementation Brief. Codex turns that into local source code, tool commands, render checks, MP4 outputs, and compact project records. ## Project Shape @@ -51,6 +53,10 @@ projects// visual-system.md refs/ iterations/ + remotion/ + package.json + src/ + public/ slides/ slides.md s01/ @@ -65,15 +71,17 @@ Use `docs/cases/` as the local Codex case-pattern library. It is allowed to extr `project.md` is a Codex-maintained small note. It should link to intake files and key local execution files instead of duplicating the outline, storyboard, page design, or execution plan. -`intake/` holds GPT V2 stage 0-5 planning Markdown, user-provided source material, references, and other accepted input files. +`intake/` holds GPT stage 0-5 planning Markdown, user-provided source material, references, and other accepted input files. `execution-plan.md` is the visual project's local execution control file. It records the current medium branch, visual-system materialization targets, small-batch iteration strategy, active `sNN` units, current round, and next decision. It does not repeat the project map from `project.md`. `visual-system/visual-system.md` records the current accepted visual system, materialization targets, iteration log, failure attribution, and next action. Character anchors, scene anchors, templates, diagrams, and backgrounds belong under `visual-system/`, not a separate `makeup-still/`. +`remotion/` is the default source root for one-off project-specific Remotion videos. It should hold source code, package files, and source assets. Generated renders, caches, dependencies, and build outputs stay out of Git by default. Reusable Remotion products/templates belong in `work-projects` unless the user explicitly keeps a prototype local. + `slides/slides.md` is the slide/page/shot execution fact table. It records each unit's source, batch, prompt version, image version, review state, acceptance state, and notes. It does not replace `execution-plan.md`. -`slides/sNN/` keeps all files for one slide, page, or shot together: prompts, narration, generated images, generated audio, review notes, and local notes. Every file inside `sNN/` must carry the `sNN` prefix; iteration files use `sNN-vN-type.ext`, such as `s03-v1-prompt.md`. +`slides/sNN/` keeps all files for one slide, page, shot, Remotion scene, or Remotion section together: prompts, narration, generated images, generated audio, component/spec notes, review notes, and local notes. Every file inside `sNN/` must carry the `sNN` prefix; iteration files use `sNN-vN-type.ext`, such as `s03-v1-prompt.md`. ## Investigations @@ -105,7 +113,9 @@ Produce a video usually under 10 minutes. Use about 220 Chinese characters per minute as the narration budget. ``` -Editing and publishing remain manual unless explicitly automated later. Image-to-video remains manual or semi-manual for now. +Editing and publishing remain manual unless explicitly automated later. Image-to-video remains manual or semi-manual for now. Remotion videos are the exception for programmatic assembly: default project-specific source goes under `projects//remotion/`, and the default deliverable is source code plus a renderable MP4. + +The user has given standing task-level permission for Remotion tasks to use `npx create-video`, npm dependency installation, and Remotion render commands when needed. The agent must still use normal sandbox/network approval requests when a command requires escalation. ## Capability-Request Mode diff --git a/docs/workflows/project-lifecycle.md b/docs/workflows/project-lifecycle.md index 612c53a..dc09f39 100644 --- a/docs/workflows/project-lifecycle.md +++ b/docs/workflows/project-lifecycle.md @@ -30,8 +30,9 @@ The phase names stay stable; the concrete work differs by medium. | MV / shot-image package | `visual-system/`, style master, character registry, `slides/slides.md`. | Core shots, character consistency, reference-loading route, callback route. | Sequential slide image packages. | | Explainer video | Script structure, terminology, visual explanation rules, voice style, asset taxonomy. | One short script section, key diagram, sample narration audio, timing check. | Script sections, diagrams, narration audio, supporting slides. | | Slide-style presentation | Page system, component patterns, visual hierarchy, case/source map. | Representative pages and transition/page-density checks. | Page batches and export-ready assets. | +| Remotion video | Remotion style-system anchor, storyboard-to-component mapping, `projects//remotion/` source root, composition plan, render target. | Scaffold or existing source check, representative scene/component, `npx remotion still` or equivalent narrow render check, MP4 render route. | React/TypeScript source updates, scene/component batches, renderable MP4 outputs, render receipts. | -Do not copy GPT planning into duplicate project truth. The accepted `intake/` files remain sources; Codex-owned local execution rules live in `execution-plan.md`, `visual-system/`, `slides/`, `tasks/`, and medium-specific control files. +Do not copy GPT planning into duplicate project truth. The accepted `intake/` files remain sources; Codex-owned local execution rules live in `execution-plan.md`, `visual-system/`, `slides/`, `tasks/`, `remotion/` when applicable, and medium-specific control files. ## Production Run State @@ -50,9 +51,11 @@ It records: - operating line; - running mode; - review mode; +- worker profile; - package size or validation override; - total target scope; - completed units; +- Remotion source root, composition ID, render target, and render output path when applicable; - active child session and callback target; - next unresolved cursor; - stop conditions; @@ -68,6 +71,7 @@ docs/workflows/slide-task-orchestration.md docs/workflows/slide-task-templates.md projects//project.md projects//execution-plan.md +projects//visual-system/visual-system.md projects//slides/slides.md projects//tasks//production-run-status.md projects//tasks//task-log.md diff --git a/docs/workflows/slide-task-orchestration.md b/docs/workflows/slide-task-orchestration.md index f0c6eec..88dc1ea 100644 --- a/docs/workflows/slide-task-orchestration.md +++ b/docs/workflows/slide-task-orchestration.md @@ -3,10 +3,11 @@ ## Status - Status: active workflow rule. -- Scope: local Video Workbench slide production tasks. +- Scope: local Video Workbench slide, scene, page, and Remotion production tasks. - First profile: `video-slide-production`. +- Remotion profile: `remotion-video-production`. -In this workflow, `slide` is the execution unit. A slide may be a video frame unit, a PPT page, or another visual page-like unit. Current rules implement video/MV slide production only. +In this workflow, `slide` is the historical execution unit. A unit may be a video frame unit, a PPT page, a Remotion scene, a Remotion section, or another visual page-like unit. Current rules implement image-led video/MV slide production and Remotion video production. ## Goals @@ -45,6 +46,36 @@ gpt-image-2 Advisor prompt/spec Garden/API use is expected to be `no` unless the user explicitly changes the project policy. +Remotion profile: + +```text +remotion-video-production +``` + +Use this profile when accepted planning material, the user, or the task says the video should be implemented in Remotion, when Codex writes or edits Remotion code, or when the expected deliverable is source code plus a renderable MP4. + +This profile uses: + +- accepted Remotion planning material in `intake/` as source specification, not as code; +- `visual-system/` and the Remotion style-system anchor as production authority; +- `slides/slides.md` as the scene/section fact table when the project decomposes into units; +- `slides/sNN/` for scene specs, component mapping notes, and render-check receipts; +- `projects//remotion/` as the default source root; +- `C:\Users\wangq\.agents\skills\remotion\SKILL.md` and task-relevant Remotion Skill rule files before code edits; +- narrow code/render validation, such as typecheck/build when available and `npx remotion still` or the task's render command. + +For Remotion work, `gpt-image-2` is used only when the Remotion project separately needs generated still assets. Remotion implementation itself is React/TypeScript source work, not image prompt work. + +Default Remotion source and output paths: + +```text +projects//remotion/ # source +projects//renders/ # rendered MP4s or still checks unless overridden +projects//exports/ # final export package when needed +``` + +One-off project-specific Remotion source belongs in Video Workbench. Reusable Remotion products, reusable templates, deployable systems, and business software belong in `work-projects` unless the user explicitly keeps a prototype local. + Reserved future profile: ```text @@ -53,12 +84,18 @@ ppt-page-production Future PPT tasks may use `docs/cases/` as an additional case-pattern knowledge base and may need a different page brief, prompt, and review structure. Do not apply `video-slide-production` rules blindly to PPT work; design that profile when the first real PPT task needs it. -Every task plan must record: +Every task plan must record the active profile, for example: ```text Worker Profile: video-slide-production ``` +or: + +```text +Worker Profile: remotion-video-production +``` + ## Operating Lines Use two lines: @@ -70,9 +107,9 @@ production-light `test/audit` is for early project setup, first visual-system proving, core-shot trials, workflow debugging, failure investigation, or explicit user-requested review. It may use richer handoffs, local review files, Agent workers, packets, returns, ledgers, parent-side inspection, completion gates, and longer narrative logs. -`production-light` is for normal production after core shots have reached the expected look. It is the default production line. It keeps only: +`production-light` is for normal production after core shots or the core Remotion route have reached the expected look. It is the default production line. It keeps only: -- content artifacts: `sNN-vN-brief.md`, `sNN-vN-prompt.md`, generated image when allowed, and `slides/slides.md`; +- content artifacts: `sNN-vN-brief.md`, `sNN-vN-prompt.md` or `sNN-vN-remotion-spec.md`, generated image or Remotion source/render output when allowed, and `slides/slides.md`; - compact recovery records: child-session handoff and one-line task log entries. In production-light, review mode defaults to: @@ -109,7 +146,15 @@ projects// s05-v1-brief.md s05-v1-prompt.md s05-v1-image.png + s05-v1-remotion-spec.md + s05-v1-render-check.md s05-v1-review.md # test/audit or explicit review only + remotion/ + package.json + src/ + public/ + renders/ + # generated render outputs ignored by default ``` Rules: @@ -117,6 +162,8 @@ Rules: - `tasks//` records orchestration and agent communication. - `slides/sNN/` remains the durable home for slide artifacts. - In `slides/sNN/`, Markdown control/script artifacts are Git-tracked by default; generated image, audio, and video files are asset-layer outputs ignored by default and referenced from control files by path, status, and hash when needed. +- `remotion/` is the default source root for project-specific Remotion videos. Source code, package files, and source assets are Git-tracked by default. +- Remotion dependencies, caches, build outputs, and rendered media are ignored by default. Record render paths and status in control files instead of committing generated media unless the user promotes a named artifact. - `intake/` and `visual-system/` are source-authority areas and should stay in Git, including approved reference images. - `archive/` is for discarded images and discarded documents by default. Do not add archive contents to Git unless the user explicitly promotes a specific item back into a source-authority area. - Task records link to slide artifacts by path and should not duplicate full prompts. @@ -138,6 +185,8 @@ Default policy: This rule applies even when the previous run was malformed. Malformed output is still evidence about the workflow and should be superseded by a new version, not silently replaced. +Remotion source files under `projects//remotion/` are ordinary code, not append-only generated artifacts. Edit them in place under Git while respecting the user's uncommitted changes. Do not delete or replace an existing Remotion scaffold just to get a clean project; inspect it and work with it. Append-only versioning still applies to scene specs, design docs, render-check receipts, generated media receipts, packets, returns, and handoffs. + ## Session Roles ### Main Session @@ -199,6 +248,7 @@ Responsibilities: - read active `visual-system/` files needed for assigned slides; - resolve the next unused slide version and write one new `sNN-vN-brief.md` per assigned slide; - in `production-light`, write `sNN-vN-prompt.md`, generate `sNN-vN-image.png`, and update `slides/slides.md` directly; +- for `remotion-video-production`, read the installed Remotion Skill and relevant rule files before code edits, write scene specs or component mapping notes as needed, update `projects//remotion/`, run narrow source/render checks, record composition IDs and render paths, and update `slides/slides.md` or task status directly; - in `production-light`, do not create slide-agent packets, do not start Agent/SubAgent workers, do not write return receipt files, and do not run a routine final verification pass; - in `production-light`, finish all project writes and narrow required checks before callback; do not continue writing after callback succeeds; - in `test/audit`, repair, or exception scopes, create one slide-agent packet per slide and start exactly one slide agent per slide, sequentially; @@ -207,6 +257,8 @@ Responsibilities: - write `child-session-handoff.md` with a compact parent-facing summary; - send the parent callback only after `child-session-handoff.md` exists. +For Remotion work, the narrow source/render checks recorded in the task plan are part of producing code and MP4 output. They are required validation, not a routine visual-review pass. + If a test/audit run needs an Agent and the runtime does not expose an Agent tool inside the child session, record this as a runtime fallback requirement in `child-session-handoff.md`. The main session may then start the slide agent as a fallback, but that run must be reported as a fallback orchestration test, not as a full child-session-owned slide-agent test. ### Slide Agent @@ -223,9 +275,11 @@ Responsibilities: - read the packet and brief; - follow the `gpt-image-2` Skill Advisor / host-native prompt workflow; +- for Remotion packets, follow the installed Remotion Skill and task-relevant rule files instead of the `gpt-image-2` workflow; - preserve visual-system reference choices in `sNN-vN-prompt.md`; - write the new-version `sNN-vN-prompt.md`; - generate an image only when the packet allows generation; +- write or edit Remotion code only when the packet explicitly uses `remotion-video-production`; - write `sNN-vN-review.md` only when required; - write a compact return receipt. @@ -247,6 +301,7 @@ The slide agent must not: - replace style-master guidance with ad hoc style text; - replace active character image references with text-only identity description when character continuity matters; - use archived style or character references unless the packet explicitly reopens them; +- invent Remotion component style outside the accepted Remotion style-system anchor unless the task explicitly asks for a new pilot; - call Minimax MCP or external review tools by default. ## Running Modes @@ -284,6 +339,51 @@ child session writes brief Generation can happen later through a separate task. +### Remotion Plan Only + +Use when the user wants Codex to translate accepted Remotion planning into local execution specs without writing source code. + +Flow: + +```text +child session reads intake + visual-system Remotion anchor +-> child session writes or updates scene specs / component mapping notes +-> child session updates slides/slides.md or task status +-> child session writes compact handoff and callbacks parent +``` + +No source code, npm command, or render command is allowed in this mode. + +### Remotion Implement + +Use when the user authorizes Remotion source work but does not request a final MP4 render. + +Flow: + +```text +child session reads Remotion Skill and relevant rules +-> child session creates or updates projects//remotion/ +-> child session writes or updates scene specs when needed +-> child session runs narrow source checks recorded in the task plan +-> child session records source paths, composition IDs, check result, and handoff +``` + +### Remotion Render + +Use when the user authorizes source work plus a renderable MP4. + +Flow: + +```text +child session reads Remotion Skill and relevant rules +-> child session creates or updates projects//remotion/ +-> child session runs narrow source checks +-> child session runs the target Remotion still/render command +-> child session records composition ID, output MP4 path, check result, and handoff +``` + +The user has given standing task-level permission for Remotion tasks to use `npx create-video`, npm dependency installation, and Remotion render commands when needed. The agent must still request sandbox or network approval at command time when required. + ## Authorization Rule The user gives the main session concrete instructions for: @@ -291,6 +391,7 @@ The user gives the main session concrete instructions for: - running mode; - slide scope; - generation permission; +- Remotion implementation or render permission; - operating line; - review or sampling expectations. @@ -298,6 +399,8 @@ If the task says `prompt only`, no image generation is allowed. If the task says `prompt and generate`, the task plan must record the authorized slide scope and exceptions. That task-level instruction is the generation approval for the named scope. In production-light, generated images are accepted into the production pass without per-image user review. Core, repair, identity-heavy, or otherwise high-risk slides may still require prompt-only handling or an explicit pause when the task plan says so. +If the task says `remotion plan only`, no source edits or render commands are allowed. If the task says `remotion implement`, source edits and narrow source checks are allowed but final MP4 rendering is not required. If the task says `remotion render`, source edits, checks, and the target MP4 render are authorized for the named scope. + ## Visual-System Requirements `visual-system/` is the production authority. @@ -309,6 +412,14 @@ For every slide: - record style module and active style references in the brief and prompt; - choose character references from `visual-system/characters/character-reference-registry.md` when a visible character matters. +For every Remotion scene or section: + +- use the accepted Remotion style-system anchor from `visual-system/remotion/` or `visual-system/visual-system.md`; +- preserve component style, information density, animation language, transition motifs, chart/flow/formula handling, and subtitle strategy from the accepted planning; +- map GPT-provided component suggestions to real React/TypeScript components during Codex implementation; +- read `C:\Users\wangq\.agents\skills\remotion\SKILL.md` and the relevant Remotion Skill rule files before code edits; +- do not use CSS transitions or CSS animations for timeline-critical motion; use Remotion frame-based animation patterns from the Skill. + For visible character slides: - text-only identity prompting is not sufficient; @@ -332,6 +443,8 @@ sNN-vN-design-en.md # optional English companion; default design remains Chine sNN-vN-brief.md sNN-vN-prompt.md sNN-vN-image.png # only when generation is allowed and succeeds +sNN-vN-remotion-spec.md # for Remotion scene/component intent when applicable +sNN-vN-render-check.md # for scene-specific Remotion still/render evidence when applicable sNN-vN-review.md # only for test/audit or explicit review ``` @@ -343,6 +456,10 @@ sNN-vN-review.md # only for test/audit or explicit review `prompt` is an attachment to the brief. It should be runnable or easy to copy into another platform for cross-validation. +`remotion-spec` is an execution-facing scene/component mapping for Remotion. It records source basis, composition/component target, text and data to render, animation intent, timing, assets, acceptance criteria, and which Remotion Skill rule files were read. It is not a replacement for React/TypeScript source. + +`render-check` records the command, composition ID, frame or render target, output path, and result for Remotion validation. + `review` is absent by default in production-light. Create it only for test/audit, core trials, identity-heavy sampling, repair targets, explicit user requests, uncertain failures, or durable reference acceptance. When review is required or suppressed, the task plan or slide-agent packet should say so explicitly. Production-light tasks default to `review: none`; test/audit tasks default to local review unless the task plan disables it. @@ -358,10 +475,11 @@ The child session must: - assigned slide versions were resolved by scanning existing `slides/sNN/sNN-v*-*` files; - no target file was overwritten unless an explicit overwrite repair authorized that exact path; - each generated slide has a project image path recorded in `slides/slides.md` and the compact handoff; +- each Remotion task records source root, composition ID, check command, check result, and render output path when rendering was authorized; - review files are absent when review mode is `none`; - the child session handoff exists before callback. -Do not run a routine final verification pass in production-light. Do not compute hashes, build file inventories, inspect generated images, or write return receipts unless the task explicitly asks for that evidence or a problem occurs. +Do not run a routine final verification pass in production-light. Do not compute hashes, build file inventories, inspect generated images, or write return receipts unless the task explicitly asks for that evidence or a problem occurs. For Remotion, the task's narrow source/render checks are required and should stay limited to the declared composition or render target. If any production-light closeout item fails, return `blocked`, `failed`, or `warning` and state what the main session should inspect. The main session then leaves lightweight production mode for that item and performs targeted inspection only. @@ -371,11 +489,13 @@ Use the fuller completion gate only in `test/audit`, repair, explicit review, or - append-only version resolution and no overwrite; - expected brief, packet, prompt, image when generation is allowed, and return files; +- expected Remotion source files, composition registration, render-check receipt, and MP4 output when Remotion rendering is allowed; - review files are present when review was required and absent when review was disabled; - exactly one owning slide agent for that slide/version when Agents are used; - each slide agent return is recorded and the agent lifecycle is terminal / closed; - required visible-context image references were loaded or the run blocked before generation; - generated project images have recorded project paths and source paths; hashes are optional unless requested; +- Remotion MP4 outputs have recorded project paths; hashes are optional unless requested; - the child session handoff contains a compact parent summary. ## Review Rule diff --git a/docs/workflows/slide-task-templates.md b/docs/workflows/slide-task-templates.md index c120391..4d0ef30 100644 --- a/docs/workflows/slide-task-templates.md +++ b/docs/workflows/slide-task-templates.md @@ -26,6 +26,8 @@ Production-light form: - Running mode: - Review mode: none - Slides: +- Remotion source root: `projects//remotion/` if applicable +- Remotion render target: - Child session: - Callback target: - Write policy: append-only; overwrite allowed: no @@ -58,6 +60,8 @@ Use a longer plan only in `test/audit`. ## Visual-System Usage +## Remotion Usage + ## Generation Evidence Policy ## Rules @@ -100,6 +104,7 @@ Use this for any production request that may continue across multiple child sess - Project: - Lifecycle phase: - Line: +- Worker profile: - Running mode: - Review mode: - Package size: @@ -112,6 +117,9 @@ Use this for any production request that may continue across multiple child sess - Completed units: - Active child session: - Next cursor: +- Remotion source root: +- Remotion composition ID: +- Remotion render output: ## Callback Target @@ -125,6 +133,7 @@ Use this for any production request that may continue across multiple child sess - Resolved versions: - Handoff path: - Image paths: +- Remotion output: - Problems: - Needs user: @@ -137,6 +146,7 @@ Field rules: - `Completed units` should list only units completed in the current production run, not every historical accepted unit. - `Next cursor` is the next unresolved unit in the authorized target set. - `User confirmation` says whether a clean callback may continue automatically or must pause for user visual confirmation. +- Remotion fields stay blank or `not applicable` for image-only tasks. For `remotion-video-production`, record source root, active composition ID, and render output path when rendering is authorized. - `Latest Callback` is updated by the parent after callback. A child session must not update project files after sending the callback. - Do not paste prompt text, full file inventories, or image review notes into this file. @@ -155,6 +165,8 @@ Production-light form: - Assigned slides: - Running mode: - Review mode: none +- Remotion source root: +- Remotion checks: - Write policy: append-only; overwrite allowed: no - Shared context: - Visual-system files: @@ -176,6 +188,10 @@ Production-light form: - Review mode: none - Resolved versions: - Image paths: +- Remotion source root: +- Remotion composition IDs: +- Remotion render outputs: +- Check commands/results: - Problems: - Needs user: - Observed elapsed/context: @@ -187,7 +203,7 @@ Handoff field rules: - `Status` states `complete`, `blocked`, `failed`, or `warning`. - `Topology` is `direct-child` for normal production-light. Use `test/audit-with-agent` only when the task explicitly uses internal slide workers. - `Review mode` states `none` for production-light unless the task explicitly changed it. -- `Resolved versions` and `Image paths` are the main continuation surface. +- `Resolved versions`, `Image paths`, and Remotion source/render/check fields are the main continuation surface. - `Observed elapsed/context` is optional and should be filled only when visible to the child or reported by the user. - `Parent summary` should be short enough that the parent can continue without opening prompt, ledger, or image files when status is clean. - Do not include full file inventories, narrative timelines, or copied prompt text in a production-light handoff. @@ -196,7 +212,7 @@ Callback payload rules: - Send the callback only after all allowed output files, `slides/slides.md` updates, narrow required checks, and `child-session-handoff.md` are complete. - The callback is the child session's final action. Do not update the handoff, run closeout checks, or write any project file after a successful callback. -- The production-light callback should include status, topology, resolved versions, handoff path, image paths if complete, and any problems or user decisions needed. +- The production-light callback should include status, topology, resolved versions, handoff path, image paths or Remotion output paths if complete, and any problems or user decisions needed. - Do not add a routine final verification pass, hashes, or per-file inventory to a clean production-light callback. - If callback cannot be sent, record the failure in `Callback Status`; the parent may then use the task's recorded polling fallback or user intervention path. @@ -225,6 +241,8 @@ Use this only in `test/audit`, explicit review, repair, exception handling, or a ## Gpt-Image-2 Advisor Rule +## Remotion Skill Rule + ## Host Generation Evidence Rule ## Generation Rule @@ -238,6 +256,12 @@ Use this only in `test/audit`, explicit review, repair, exception handling, or a ## Return File ``` +Packet field rules: + +- Use `Gpt-Image-2 Advisor Rule` only for image-generation packets. +- Use `Remotion Skill Rule` for `remotion-video-production` packets. It must name `C:\Users\wangq\.agents\skills\remotion\SKILL.md`, the task-relevant Remotion `rules/*.md` files to read, the source root, allowed source edits, and required check/render commands. +- A packet must not authorize both image generation and Remotion rendering unless the task explicitly needs generated still assets inside a Remotion project. + ## Slide Agent Return Use this only when a slide agent was actually launched. Production-light direct-child packages do not write slide-agent returns. @@ -350,6 +374,8 @@ Brief field rules: For Video Workbench image generation, the brief should treat `gpt-image-2` as prompt/spec Advisor only. It should not require or expect Garden/API execution unless the task plan explicitly changes the project policy. +For Remotion production, the brief should point to the accepted Remotion planning source and Remotion style-system anchor. It should not include React/TypeScript source code; code belongs under `projects//remotion/`. + ## Slide Prompt ```text @@ -382,6 +408,79 @@ Prompt field rules: - Do not put long project explanation, detailed source audit, review conclusions, or task orchestration history in normal prompt files. - For Video Workbench, final prompts may name local paths for traceability, but the prompt must also say that the actual reference image must be loaded into visible context before host image generation when identity/reference control matters. +## Remotion Scene Spec + +Use this for `remotion-video-production` when a scene, section, or component needs an execution-facing mapping before or alongside source edits. + +```text +# S-NN Remotion Spec V1 + +## Status + +## Based On Sources + +## Scene / Section Function + +## Remotion Style Anchor + +## Composition / Component Target + +## Text / Data / Assets + +## Timing And Voiceover Relationship + +## Animation Intent + +## Component Mapping + +## Required Remotion Skill Rules + +## Acceptance Checklist + +## Source Handoff +``` + +Remotion spec field rules: + +- `Based On Sources` links to accepted `intake/` files, Remotion Implementation Briefs, and relevant visual-system files. +- `Composition / Component Target` names the intended composition ID or component path when known. If unknown, say `to be decided by Codex implementation`. +- `Text / Data / Assets` lists the text, values, diagrams, audio, images, or public assets the scene must render. +- `Timing And Voiceover Relationship` records duration, frame range, narration beat, subtitle/caption relationship, or `not applicable`. +- `Animation Intent` describes motion as explanation, not decoration. +- `Required Remotion Skill Rules` lists `C:\Users\wangq\.agents\skills\remotion\SKILL.md` and any read `rules/*.md` files, such as `rules/video-layout.md`, `rules/timing.md`, `rules/transitions.md`, `rules/subtitles.md`, or `rules/audio.md`. +- `Source Handoff` states what must be implemented under `projects//remotion/`. + +## Remotion Render Check + +Use this when a Remotion still, source check, or MP4 render was run. + +```text +# S-NN Remotion Render Check V1 + +## Status + +## Source Root + +## Composition ID + +## Commands + +## Output Paths + +## Result + +## Issues + +## Next Action +``` + +Render check field rules: + +- `Commands` records exact commands run, such as typecheck/build, `npx remotion still`, or `npx remotion render`. +- `Output Paths` records still and MP4 output paths. Generated media stays ignored by default unless the user promotes a named file. +- `Result` states pass, blocked, failed, or warning. +- Keep this compact. Do not paste full command logs unless the error text is needed for diagnosis. + Artifact version / write policy rules: - Use a new slide version for every new task execution. Do not reuse an existing `vN` just because an earlier version is incomplete. @@ -389,6 +488,7 @@ Artifact version / write policy rules: - The child session, and any slide-agent packet when one is used, must state `Overwrite allowed: no` by default. - Before writing any output path, check whether the target file exists. If it exists and overwrite is not explicitly authorized for that exact file, stop and return an artifact-collision blocker. - Do not backfill missing brief or prompt files for an old generated image as if they were original generation inputs. If backfill is needed for analysis, label it as reconstruction / audit, not as the original prompt. +- Remotion source files under `projects//remotion/` are normal code and may be edited in place under Git. Do not replace an existing Remotion scaffold without inspecting it. Append-only versioning still applies to Markdown specs, render-check receipts, generated media receipts, packets, returns, and handoffs. ## Slide Review