Compare commits

...

24 Commits

Author SHA1 Message Date
wantsong 63772412b4 docs: add remotion workflow rules 2026-07-07 18:11:45 +08:00
wantsong 31b920e819 Add deck project text records 2026-07-07 17:11:01 +08:00
wantsong 65ee8eb1dc 记录媒体资产入库策略 2026-06-26 06:19:36 +08:00
wantsong 484c34c7a9 补充conda环境规则 2026-06-26 05:52:20 +08:00
wantsong 05e8a60069 完成在路上生产编排完成所有镜头制作 2026-06-25 10:22:34 +08:00
wantsong c850a260e2 完成第6轮测试,增加订阅制 2026-06-25 05:49:49 +08:00
wantsong fc681035c8 完成第五轮测试和回调调研 2026-06-24 20:58:05 +08:00
wantsong 8375713be6 完成流程的第4轮测试 2026-06-24 17:40:41 +08:00
wantsong e64f6929cf 完成第3次流程测试及优化 2026-06-24 16:24:07 +08:00
wantsong 9ffb6e5341 第三轮测试派发子会话改为新子会话 2026-06-24 15:08:48 +08:00
wantsong f4e0e04c43 完成工作流的第1和第2轮优化 2026-06-24 14:59:40 +08:00
wantsong 847e5ca2c1 完成流程编排 2026-06-24 10:16:01 +08:00
wantsong 45ac41f754 完成人物一致性调研 2026-06-24 08:11:14 +08:00
wantsong 4a2fe78821 增加人物一致性单镜骨架 2026-06-24 07:02:09 +08:00
wantsong 8cad95753f style规则制订及清理 2026-06-24 06:34:25 +08:00
wantsong 9b1a3c331d visual-system/characters规则及清理 2026-06-24 05:57:40 +08:00
wantsong 4329653844 Broad-run images are candidates, not accepted finals. Identity/style reference workflow needs repair before further generation. 2026-06-24 05:36:47 +08:00
wantsong c37e7ab308 Add accepted visual anchors and five-shot trial 2026-06-23 18:32:11 +08:00
wantsong 1af1ce1960 Initialize On The Road video project 2026-06-23 13:25:58 +08:00
wantsong 822b7456fe docs: 完成 video workbench 重构案例库 2026-06-23 08:46:13 +08:00
wantsong c7e208a99e docs: archive video workflow investigations 2026-06-23 08:08:48 +08:00
wantsong b12502bf8c docs: align video workbench with GPT V2 workflow 2026-06-23 07:58:44 +08:00
wantsong 74ffd3ba18 docs: align video workbench rules with CCPE interface 2026-06-22 13:45:46 +08:00
wantsong 94043faba5 chore: simplify video workbench structure 2026-06-22 13:10:13 +08:00
728 changed files with 79378 additions and 594 deletions

39
.gitignore vendored Normal file
View File

@ -0,0 +1,39 @@
tmp/*
!tmp/.gitkeep
garden-gpt-image-2/*
!garden-gpt-image-2/.gitkeep
# Generated / discarded project assets
projects/**/slides/s*/*.png
projects/**/slides/s*/*.jpg
projects/**/slides/s*/*.jpeg
projects/**/slides/s*/*.webp
projects/**/slides/s*/*.gif
projects/**/slides/s*/*.mp4
projects/**/slides/s*/*.mov
projects/**/slides/s*/*.avi
projects/**/slides/s*/*.mkv
projects/**/slides/s*/*.wav
projects/**/slides/s*/*.mp3
projects/**/slides/s*/*.m4a
projects/**/slides/*.pdf
projects/**/slides/*.pptx
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

200
AGENTS.md Normal file
View File

@ -0,0 +1,200 @@
# Video Workbench Agent Rules
## Text Encoding
All local project documents are UTF-8 unless a file explicitly declares another encoding.
When reading Markdown, JSON, YAML, text, handoff, prompt, or discussion files from PowerShell, use explicit UTF-8 by default:
```powershell
Get-Content -LiteralPath <path> -Encoding UTF8
Select-String -Path <path> -Pattern <pattern> -Encoding UTF8
```
When writing text files, preserve UTF-8. Do not rely on PowerShell encoding defaults for Chinese Markdown.
## Python / Conda Environment
For local Python automation, validation, indexing, and helper scripts in this repository, default to the shared `skills-vault` Conda environment.
Preferred command pattern:
```powershell
& 'C:\Users\wangq\miniconda3\Scripts\conda.exe' run -n skills-vault python -B <script-or-module>
```
If `conda` is already available on PATH, this may be shortened to:
```powershell
conda run -n skills-vault python -B <script-or-module>
```
Do not treat missing packages in the system Python, such as `yaml` / PyYAML, as project evidence failures. Use the `skills-vault` environment first.
Do not install project dependencies into the system Python as the default fix. Create or use a separate Conda environment only when a task has special dependencies, dependency conflicts, or an explicit project-local environment contract.
## CCPE Interface
The default external CCPE entrypoint is:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
For CCPE setup or invocation work, read that file first, then follow it to:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-setup.md
```
Do not hardcode old Agent, Lite, Skill, Runtime, or protocol paths as default CCPE entrypoints. Read narrower CCPE artifacts only when the consumer setup contract, a project-local registry, or the active task requires them.
Formal CCPE participant output requires a project-local registry, an invocation packet, a real participant carrier, and returned output saved only after the participant returns. Main-session roleplay is not formal CCPE output.
## Image Prompt Workflow
All image-generation prompts in this repository must be produced through the `gpt-image-2` Skill workflow. Do not draft final image prompts directly from memory or from a derived project skeleton alone.
Before writing any project-bound image prompt, run the Skill mode check and follow the resulting mode:
```powershell
node C:\Users\wangq\.agents\skills\gpt-image-2\scripts\check-mode.js --json
```
- Mode A: use the Skill's Garden generation/edit scripts and save prompt/image traces under `garden-gpt-image-2/`.
- Mode B: use the Skill as a prompt-engineering workflow, save the rendered prompt, then pass it to the host image tool only after user approval.
- Mode C / Advisor: use the Skill as a high-quality prompt advisor, save the rendered prompt, and do not claim an image was generated.
Current default success path for project-bound image generation:
1. Generate the final prompt/spec with the `gpt-image-2` Skill Advisor workflow.
2. When image references are needed, load the real reference image into the conversation context before generation.
3. Use the host `image_gen` tool with the loaded reference image assigned an explicit role such as `Image 1`.
Use this successful channel now and for future work. Do not switch normal Video Workbench image generation to API/Garden paths unless the user explicitly changes this policy.
For every project-bound image prompt document:
- Read the relevant `gpt-image-2` Skill template or reference file before drafting.
- Record the Skill mode, template/reference path, and source files actually read.
- Treat accepted `intake/` files and user-provided references as primary sources; use derived files such as `visual-system.md`, `execution-plan.md`, or `slides/slides.md` only as execution control summaries.
- If a prompt was drafted without the Skill workflow, label it as a non-generation-ready draft and rebuild it through the Skill before any image generation.
- When a local image outside the workspace is used, label its role explicitly as identity reference, edit target, or supporting reference, and do not proceed if the file cannot be read or approved.
- For near / identity-heavy shots, prefer a relevant crop reference. For distant / landscape-led shots, prefer the accepted anchor board or project-approved distant reference. Do not repeatedly re-ask whether references can work; the verified route is Skill Advisor prompt plus loaded reference image plus host `image_gen`.
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/<project>/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/<project>/remotion/public/` unless the project has a better local convention;
- place rendered MP4s or render tests under `projects/<project>/renders/`, `projects/<project>/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, including Remotion scene or section production, use the local slide task orchestration workflow:
```text
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
```
### Runtime Vocabulary / Default Carrier
Use these terms as the default implementation contract for Video Workbench slide tasks. Do not re-investigate old session artifacts or broad runtime mechanism docs just to infer this mapping.
| User term | Meaning | Default carrier |
| --- | --- | --- |
| `子会话` / `session` | A user-visible separate Codex session for brief / orchestration work, started from a clean prompt rather than inherited orchestration history. | `codex_app.create_thread` to create, `codex_app.send_message_to_thread` to continue, `codex_app.read_thread` to inspect. |
| `继续前子会话` | Continue the already recorded visible child session instead of creating a new one. | Send the next instruction to the recorded `threadId`. |
| `Agent` / `SubAgent` | An internal one-shot worker used for test/audit, exception handling, or explicitly isolated slide work. It is not the default production-light carrier. | `multi_agent_v1.spawn_agent(agent_type="worker")`; one worker handles exactly one slide when used. |
| `无 review` / `review: none` | Review is disabled for the named scope. This is the production default after the test / audit line has established the project's core look. | Do not write `sNN-vN-review.md`; record only compact status, image paths, and task-log / handoff notes needed for continuation. |
Do not use `codex_app.fork_thread` as the default carrier for production child sessions. Forking copies completed orchestration history from the parent thread and can contaminate the child session's context. Use `fork_thread` only when the user explicitly wants an inherited-context branch.
If the default tools are not already exposed in a new session, use `tool_search` to expose `create_thread`, `send_message_to_thread`, `read_thread`, and `spawn_agent` by name, then proceed with this contract.
Default preflight for a slide/session run:
- confirm the target visible session id or create exactly one new clean visible session with `create_thread`;
- when creating a visible child session, set or request a user-facing title beginning with `子会话:` followed by the project / package name, so the session is distinguishable in the Codex UI;
- scan the target slide folder for the next unused `sNN-vN-*` version;
- set `Overwrite allowed: no`;
- read the project phase from `projects/<project>/project.md`; new projects default to `test/audit` until the user explicitly authorizes formal production;
- record the active line, either the project default or a user-authorized override for a named session / scope;
- record review mode; production-light defaults to `review: none`;
- use direct-child production in `production-light`; launch internal one-shot SubAgents only in `test/audit`, explicit review, repair, or exception scopes.
Use two operating lines:
- `test/audit`: use when building or debugging the workflow, proving a new project look, testing core shots, or investigating failures. Local review, richer ledgers, and longer handoffs are allowed.
- `production-light`: use after core shots have reached the expected look. This is the default normal production line once authorized in `project.md`. It keeps the content line (`brief`, `prompt`, generated image, `slides/slides.md`) and compact recovery receipts, but omits routine audit reports.
Production orchestration defaults:
- The main session dispatches the approved scope, records the parent thread id as the callback target, then stops routine waiting. It should not poll the child thread for routine completion.
- The production-light child session directly writes briefs, prompts, images, `slides/slides.md` updates, and a compact handoff. It does not launch Agent/SubAgent workers by default.
- The child session completes all allowed project writes, `slides/slides.md` updates, narrow required checks, and compact handoff writing before callback.
- The child session sends a concise callback to the parent with `codex_app.send_message_to_thread` as its final action. After a successful callback, it must not write or verify additional project files.
- The callback payload must include status, topology, resolved versions, handoff path, image paths if complete, and any problems or user decisions needed.
- After the callback wakes the parent, the parent reads the child session's short handoff and continues. It should not audit prompt / image details when the child session reports `complete` with no problems.
- The old sleep / poll schedule is a fallback only when callback tooling is unavailable or the user explicitly requests polling for a named run. If used, record the fallback in the task plan.
- The production-light child session keeps only the mandatory write guard: resolve the next unused version by scanning existing files, do not overwrite, record image paths, update required status files, perform only narrow required checks, and write a compact handoff before callback. Do not run a routine final verification pass.
- In `test/audit`, repair, or exception scopes, the child session may run the fuller completion gate: append-only version, no overwrite, expected files present, review present or absent as instructed, one owning worker per slide/version when workers are used, references loaded or blocked, and compact handoff written.
- Instruction / visual review is optional. In production-light, the default is `review: none`: generated images are recorded as production-pass outputs without per-image user review, and the user may request an append-only retry later if the result is not usable.
- A slide `Agent` / `SubAgent`, when used, is one-shot. It receives one packet, handles one slide/version, writes one return, then becomes terminal / closed. Do not continue or reuse a closed Agent; repairs, retries, and next slides require a new Agent.
Re-investigate runtime mechanics only when a tool is unavailable or errors, when an Agent becomes a user-visible session, when duplicate workers target the same slide/version, when target files collide, or when the user explicitly asks to revise the mechanism.
Rules:
- Use `projects/<project>/tasks/<task-id>/` for local orchestration records.
- The main session talks with the user and defines worker profile, running mode, slide scope, and review expectations.
- 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.
- For design-gated slides, write `design` first and wait for user confirmation before writing `brief`, `prompt`, or generating the image, unless the user explicitly authorizes the full chain in one task.
- `visual-system/` is the production authority for slide work.
- `intake/` and `visual-system/` are project source authorities and should stay in Git, including approved reference images.
- Style continuity must use `visual-system/style/style-prompt-master.md`.
- 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/<project>/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.
- Review defaults to `none` in production-light and local-only in test/audit or explicit review tasks. Do not call Minimax MCP or other external vision/review services unless the user explicitly authorizes that task.

View File

@ -6,7 +6,7 @@ This file is the local project map for Video Workbench. It exists so future sess
`video-workbench` is the local production workspace for dimensional video output.
It turns deep source material into public-facing video packages, including:
It turns accepted planning material and deep source references into public-facing video or slide-style execution packages, including:
- series architecture;
- episode scope;
@ -15,6 +15,7 @@ It turns deep source material into public-facing video packages, including:
- video outlines;
- storyboard logic;
- shot-level production files;
- project-specific Remotion source and render receipts;
- voiceover scripts;
- image prompts;
- asset manifests;
@ -29,17 +30,18 @@ It does not own upstream deep creation, canonical agents, reusable automation so
| --- | --- | --- | --- |
| `knowledge-vault` | Upstream knowledge, source archive, formal essays, human-readable model documents, and discussion memory | stable essays, model documents, selected source notes, source paths, discussion records with formed conclusions | optional pointers from video packages back to source materials |
| `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 | CCPE-Lite actors, agent specs, runtime rules, invocation contracts, model usage rules | capability requests under `requirements/ccpe/` |
| `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
- Video Workbench is a sibling of Writing Workbench, not a child project.
- Deep article creation belongs in `writing-workbench`.
- 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`.
- 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/<project>/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.
@ -50,8 +52,7 @@ Video Workbench is a client and production room:
```text
knowledge-vault provides sources and long-term knowledge.
writing-workbench may provide stable article projects.
ccpe-system provides local work agents, protocols, and model assets.
ccpe-system provides local work agents, protocols, and model assets through `Interface.md`.
skills-vault provides deterministic automation tools.
video-workbench runs the video project and keeps the production record.
video-workbench runs local projects under `projects/` and keeps lightweight execution records.
```

120
README.md
View File

@ -1,85 +1,83 @@
# Video Workbench
Video Workbench is the production workspace for dimensional output: turning deep essays, models, and ideas into short public-facing video packages.
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.
## Position
## Working Model
```text
Knowledge Vault = source archive, formal essays, human model documents, historical discussions
Writing Workbench = deep article production workspace
Video Workbench = dimensional video output production workspace
CCPE System = AI cognitive asset engineering workspace
Delivery Systems = deployable external agentic products
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, 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
```
See `PROJECTS.md` for the local project relationship map and ownership boundaries.
Video Workbench is not the canonical home for prompts, agents, reusable automation source, deep essays, or finished article writing.
## Mission
## Main Layout
This workspace manages the process of extracting one or two accessible points from deep essays or models and producing a video-ready package, usually under 10 minutes.
```text
projects/
project-id/
project.md
intake/
execution-plan.md
visual-system/
visual-system.md
refs/
iterations/
remotion/
package.json
src/
public/
slides/
slides.md
s01/
s02/
It preserves:
handoff/
docs/
cases/
investigations/
garden-gpt-image-2/
requirements/
ccpe-consumption/
```
- series architecture
- episode scope
- angle proposals
- selected angle
- video outline
- global visual style
- storyboard logic
- shot-level deep production
- voiceover script
- image prompts
- generated image/audio assets
- editing notes
- publishing copy
- `projects/` is the only project entry point. Project status and series membership are recorded inside project files, not by moving directories.
- `projects/<project>/intake/` holds user-provided GPT stage 0-5 Markdown, source notes, references, and other accepted inputs.
- `projects/<project>/project.md` is a Codex-maintained project note and file map. It should link to content in `intake/`, not duplicate it.
- `projects/<project>/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/<project>/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/<project>/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/<project>/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.
- `investigations/` is for research reports, experiments, comparisons, and draft workflow proposals. It replaces `tmp/` for durable investigation evidence.
- `garden-gpt-image-2/` is reserved for local image-generation prompt/workflow traces when that tool path is used.
Series indexes can be added later under `projects/_series/` when a real series needs more than project-local notes.
## Boundaries
- Deep essays and human model documents remain in `knowledge-vault`.
- Deep article creation remains in `writing-workbench`.
- Actors, Skills, Model Cards, and Runtimes are maintained in `ccpe-system`.
- Deterministic reusable automation tools are maintained in `skills-vault`.
- Video Workbench records production work and capability requests; it does not store canonical prompts or agent definitions.
- Manual editing and publishing remain human-controlled unless explicitly automated later.
## Two Modes
### Execution Mode
Use existing sources, agents, skills, files, and project records to complete work for a video package.
Execution mode may:
- prepare source maps and source digests;
- create series or standalone project records when requested;
- prepare angle proposals, outlines, storyboards, shot files, scripts, prompts, asset logs, editing notes, and publishing copy;
- call existing CCPE assets or automation skills when they are available and appropriate;
- record user decisions and project status.
Execution mode must not invent missing formal agent output or treat a planned capability as already executed.
### Capability-Request Mode
When an agent, skill, runtime, model card, invocation protocol, or deterministic automation tool is missing, create a supplier ticket and pause that capability-dependent part of the project.
Tickets go to:
```text
requirements/ccpe/
requirements/skills-vault/
```
CCPE supplies local work agents, runtime rules, model cards, invocation contracts, governed cognitive assets, and external capability registrations.
Skills-vault supplies deterministic automation tools, scripts, batch utilities, exporters, and installable automation skills.
- 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/`.
- Missing reusable automation should be requested under `requirements/skills-vault/`.
- All local Markdown, JSON, YAML, text, prompt, discussion, and handoff files are UTF-8 by default. PowerShell reads should use explicit `-Encoding UTF8`.
- The default CCPE external interface is `C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md`; follow it to the consumer setup contract before reading narrower CCPE artifacts.
## Starting A New Session
In a new Codex session opened on this project, use:
```md
Please read README.md, VIDEO_WORKBENCH.md, docs/context-handoff.md, and docs/ccpe-system-handoff.md first, then continue work on Video Workbench according to those conventions.
Please read AGENTS.md, README.md, VIDEO_WORKBENCH.md, docs/context-handoff.md, and docs/ccpe-system-handoff.md first, then continue work on Video Workbench according to those conventions.
```

View File

@ -2,71 +2,342 @@
## 1. Workspace Identity
This project is the dimensional video output workspace.
This project is the local execution workspace for dimensional video, Remotion, and slide-style output.
It turns deep source material into public-facing short video production packages. It is optimized for accessibility, rhythm, metaphor, visual planning, and asset preparation.
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. Operating Principle
One video should usually explain one or two points.
The goal is not to compress a deep article into a shorter article. The goal is to extract a public-facing angle from a deep model or essay and rebuild it as a video-native experience.
## 3. Source Inputs
Typical sources:
## 2. Collaboration Roles
```text
knowledge-vault/sayings
knowledge-vault/rules
knowledge-vault/sources
knowledge-vault/discussions
writing-workbench/projects
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, Remotion implementation, visual-system materialization, iteration, local assets
```
Common 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.
- one long essay
- one human-facing model document
- selected source notes
- Deep Research reports
- a target audience/topic
- optional series plan
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.
Video Workbench is normally downstream of already formed source material. It may start from different upstream entrances when the user asks, but it should not quietly turn open-ended deep creation into a video production project.
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`.
## 4. Production Types
## 3. Project Layout
Use `series/` when a long essay or model needs multiple episodes.
Use `standalone/` when the output is a single independent video.
Recommended project ids:
All video or slide-style work lives under `projects/`:
```text
series/active/YYYY-MM-DD-sNNN-temp-series/
standalone/active/YYYY-MM-DD-vNNN-temp-topic/
projects/
project-id/
project.md
intake/
execution-plan.md
visual-system/
visual-system.md
refs/
iterations/
remotion/
package.json
src/
public/
slides/
slides.md
s01/
s02/
tasks/
```
Do not rely on final titles in folder names. Titles can evolve inside `series.md`, `episode.md`, or publishing files.
Use root-level `handoff/` for repository-level, cross-project, series-level, or context-window handoff notes.
## 5. Canonical Episode Stages
Use `docs/cases/` for Codex-side local case patterns extracted from old real GPT cases. These documents preserve reusable structure, granularity, asset layering, speaker-note style, and review dimensions. They do not restore old GPT final prompts, Codex JSON execution packages, output paths, or global text-rendering rules.
The workflow maps to the user's prior dimensional output process:
Do not split projects into `active`, `completed`, `abandoned`, `series`, or `standalone` folders. Status and series membership belong in project files because both can change during real production.
If a series needs more structure, create `projects/_series/` when the first real series needs it.
## 4. Project Notes
`projects/<project>/project.md` is a lightweight Codex-maintained note. It should record:
- project status;
- 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 planning Markdown, source notes, reference notes, or background notes;
- Remotion source root when applicable, defaulting to `projects/<project>/remotion/`;
- current execution focus;
- key local execution files;
- next action.
It should not duplicate the full outline, storyboard, page design, shot design, or execution plan.
## 5. Execution Plan
Visual projects must have:
```text
00-architecture = series/episode architecture, source selection, word budget
01-proposals = three distinct angle proposals
02-tone-outline = selected angle, core anchor, metaphor, visual style, global prompt
03-storyboard = storyboard logic and time budget
04-deep-production = shot-level visual plan, image prompts, voiceover, design notes
05-assets = generated images, audio, optional video clips, asset log
06-editing = manual edit notes and timeline plan
07-publish = title options, description, platform copy, final script
08-review = review notes and postmortem
projects/<project>/execution-plan.md
```
## 6. Word Budget
Global lifecycle rules live in:
```text
docs/workflows/project-lifecycle.md
```
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;
- the next decision.
It should not repeat the project ID, full intake file index, or project map from `project.md`.
## 6. Intake
`projects/<project>/intake/` holds material provided or accepted by the user:
- 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.
File naming can be agreed during the first real project. Do not create a rigid naming scheme before the real GPT outputs are known.
### Intake Heading Repair
When copied GPT / LLM intake Markdown has broken heading hierarchy, use the installed `fix-title` Skill as an external repair capability, but keep the calling protocol local to Video Workbench.
Local calling rules:
- Repair work must run through a real Agent / subagent invocation when the runtime provides one.
- The main session should pass the source file paths, `mode=artifact` or `mode=discussion`, the `fix-title` skill path, and the output directory to the worker.
- The main session should not build semantic heading plans or apply heading edits itself when an Agent carrier is available.
- For files under `projects/<project>/intake/`, output must go under:
```text
projects/<project>/intake-repair/fix-title-YYYY-MM-DD-<short-slug>/
```
The repair output package should contain:
```text
<stem>.heading-map.json
<stem>.heading-plan.json
<stem>.fixed.md
<stem>.heading-report.md
fix-title-batch-report.md
```
If repaired files replace originals, first copy the original Markdown files to:
```text
projects/<project>/intake-repair/fix-title-YYYY-MM-DD-<short-slug>/originals-before-replacement/
```
Main-session responsibilities after the worker returns:
- verify the returned files exist;
- inspect the heading map, plan, fixed copy, per-file report, and batch report;
- check that intended artifact files have one clear document title unless the report flags an intentional appended artifact;
- check that ambiguous appended artifacts are reported instead of silently merged;
- decide whether to replace originals, and write replacement notes when replacement happens.
Do not put durable intake repair output under `tmp/`. Keep reusable automation changes in `skills-vault`; Video Workbench owns only the local invocation protocol, project evidence, replacement notes, and supplier-request records.
## 7. Visual System
Visual projects use:
```text
projects/<project>/visual-system/
visual-system.md
refs/
iterations/
```
`visual-system.md` is the single record for the project's public visual system. It should cover:
- the current accepted visual system;
- materialization targets;
- trial prompts and generated reference assets;
- review notes;
- failure attribution;
- next action.
Use optional subfolders only when the project needs them:
```text
visual-system/characters/
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/`;
- record the active references and their intended use in `visual-system/characters/character-reference-registry.md`;
- move historical candidates, rejected versions, prompt/review process files, previews, masks, chroma sources, and other intermediate files to `archive/characters/`;
- do not use files under `archive/characters/` as default prompt references unless a repair task explicitly reopens them.
For identity-critical shots, prompt specs must choose the person reference from the active character registry. Text description can clarify the role, but it does not replace the active character image reference.
## 8. Slides And Shots
Use `slides/` as the execution unit area for video shots, PPT-style pages, Remotion scenes, and Remotion sections.
`projects/<project>/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, shot, Remotion scene, or Remotion section together:
```text
slides/
slides.md
s01/
s01-metadata.json
s01-unit-spec.md
s01-v1-design.md # optional; required for cover/PPT/science-video/title/post-production pages
s01-v1-design-en.md # optional English companion; default design remains Chinese
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
s01-v2-review.md # optional; test/audit or explicit review only
```
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, 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`, 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/<project>/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.
### Slide Task Orchestration
For long or context-heavy production, use local slide task orchestration:
```text
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
```
Project-local task records go under:
```text
projects/<project>/tasks/<task-id>/
```
Task records are for orchestration only. Durable slide artifacts remain under `slides/sNN/`.
For production work that may span multiple child sessions, keep a compact continuation file:
```text
projects/<project>/tasks/<task-id>/production-run-status.md
```
This file records the target scope, completed units, active child session, next cursor, latest callback, and stop conditions. It is the default recovery surface after parent-session compression. It is not a review report and should not duplicate prompts or image evidence.
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/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 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.
- Test/audit topology: main session -> child session -> optional slide Agent.
- Slide agent capacity when used: exactly 1 slide.
- Execution is sequential by default; do not run child sessions or slide agents in parallel unless the user explicitly changes the rule.
- Parent orchestration is callback-only by default: after dispatch, the main session stops routine waiting; the child session wakes the parent with status, topology, resolved versions, handoff path, and image paths if complete.
- Callback is the child session's final action: all allowed project writes, `slides/slides.md` updates, narrow required checks, and the compact handoff must be complete before callback; after a successful callback the child must not write or verify additional project files.
- Polling is a fallback only when callback tooling is unavailable or the user explicitly requests polling for a named run.
- Production-light review mode: `none`.
- Future `ppt-page-production` work is reserved and may use `docs/cases/`, but it must not inherit video-slide rules blindly.
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 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.
Visual-system rules:
- `visual-system/` is the production authority.
- Style continuity must use `visual-system/style/style-prompt-master.md`.
- 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/<project>/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/<project>/remotion/public/` for assets referenced with Remotion `staticFile()` unless a task records a different local convention.
- Use `projects/<project>/renders/` or `projects/<project>/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:
- Production-light review defaults to `none`.
- 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-id>/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
Use `investigations/` for research reports, experiments, comparisons, draft workflow proposals, and other reviewable evidence.
`tmp/` is deprecated and should not receive new durable work. Short-lived scratch material should either be deleted or promoted into `investigations/` when it becomes useful evidence.
`garden-gpt-image-2/` remains reserved for tool-level image prompt or workflow traces when that path is used.
## 10. Word Budget
Use the default standard:
@ -77,25 +348,69 @@ Use the default standard:
Adjust only when the user specifies a different narration speed.
## 7. Asset Policy
## 11. Asset Policy
Image and audio generation can be automated when APIs and models are available.
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 in the initial version.
Editing and publishing are human-controlled unless explicitly automated later.
## 8. Two Modes
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.
### Execution Mode
For project-bound image prompts, Codex must:
Use existing project files, source materials, CCPE assets, and automation skills to produce or update a concrete video package.
- run the `gpt-image-2` mode check before prompt work;
- read the relevant Skill template or reference file;
- save the rendered prompt/spec as a reviewable project file;
- list the source files actually used;
- wait for user approval before image generation.
Execution mode may create and update project records, production files, user decision records, source maps, outlines, storyboards, scripts, prompts, asset logs, editing checklists, and publishing copy.
A task-level user instruction that records `prompt and generate` plus the slide scope counts as generation approval for that task scope. A task recorded as `prompt only` never authorizes image generation.
Execution mode must not role-play a missing expert agent, mark planned skills as executed, or promote exploratory notes into formal outputs without user direction.
Direct prompts may exist only as clearly labeled scratch or non-generation-ready drafts. They must be rebuilt through the `gpt-image-2` Skill workflow before use.
### Capability-Request Mode
### Reference-Capable Image Generation
The current and future default success path for project-bound reference generation is:
```text
gpt-image-2 Skill Advisor prompt/spec
→ load the real reference image into the conversation context
→ call host image_gen with the loaded image assigned an explicit role
→ copy the selected output into the project or investigation
→ record prompt, input reference path, output path, and compact handoff/status
```
This route was validated in:
```text
investigations/2026-06-24-s14-reference-capable-generation/
```
Use this path instead of API/Garden image generation for normal Video Workbench work. Do not reopen the "can references work" question for ordinary project-bound image generation unless the host image tool is unavailable, the reference file cannot be loaded, or the user explicitly changes the policy.
For every reference-capable generation:
- the prompt must still be produced through the `gpt-image-2` Skill workflow;
- the actual image reference must be loaded into the conversation context before generation;
- the prompt must name the loaded image role, such as `Image 1: identity reference`, `Image 1: style reference`, or `Image 1: edit target`;
- merely writing a local path in the prompt is not enough;
- the output must be copied from the host-generated default location into the project, investigation, or other durable workspace path;
- the compact handoff or task status must record whether the generation used the verified host reference-by-visible-context path; a slide-agent return receipt is required only when the task actually uses a slide Agent in test/audit, repair, exception, or explicit review mode.
Reference selection defaults:
| Shot or asset need | Default reference choice |
| --- | --- |
| Near shot, face, half-profile, expression, identity-heavy frame | Use the matching crop reference first. |
| Distant shot, landscape-led frame, aerial / wide scene, low identity burden | Use the accepted character anchor board or project-approved distant reference first. |
| Medium action, back view, walking pose, prop continuity | Use the matching crop, transparent slice, or anchor board according to the visible direction. |
| High identity fidelity project with many close shots | Consider creating higher-resolution crops through image-to-image from the accepted anchor board before production. |
For `在路上`-style landscape-led MV projects, a crop set derived from the accepted character anchor board and made transparent is sufficient by default when the goal is consistency rather than high-fidelity portrait likeness.
## 12. Capability-Request Mode
When a required capability is missing, create a supplier ticket and pause the dependent work.
@ -110,27 +425,33 @@ Use `requirements/ccpe/` for local work agents, CCPE-Lite artifacts, agent specs
Use `requirements/skills-vault/` for deterministic automation tools, scripts, exporters, batch processors, and installable automation skills.
## 9. CCPE Consumption
## 13. Text Encoding
Video Workbench consumes CCPE assets from:
All local project documents are UTF-8 unless a file explicitly declares another encoding.
```text
C:\Users\wangq\Documents\Codex\ccpe-system
When using PowerShell to read Markdown, JSON, YAML, text, handoff, prompt, or discussion files, use explicit UTF-8:
```powershell
Get-Content -LiteralPath <path> -Encoding UTF8
Select-String -Path <path> -Pattern <pattern> -Encoding UTF8
```
Likely assets:
Do not wait for mojibake or a failed first read before applying UTF-8.
- Qiangge's Apprentice / dimensional output actor
- series architect
- angle proposal skill
- video outline skill
- storyboard skill
- shot deep-production skill
- image prompt generator
- voiceover script generator
- visual style model card
- short video production runtime
## 14. CCPE Consumption
Do not duplicate canonical CCPE definitions here. Use `ccpe-consumption/` for links, usage notes, planned dependencies, and task-specific adapters.
Video Workbench consumes CCPE through the single external interface:
Local work prompts and agents belong in CCPE. If this workflow is later packaged as deployable software, production/business agent implementation belongs in the target software project, not in Video Workbench.
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
When preparing CCPE integration or invocation work, read `Interface.md` first and follow it to:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-setup.md
```
Do not duplicate canonical CCPE definitions here. Do not hardcode Agent, Lite, Skill, Runtime, or protocol paths as default entrypoints. Use `ccpe-consumption/` for interface notes and future project-local invocation setup records.
Reusable or canonical expert agents belong in CCPE. Project-local slide task orchestration, child-session records, and slide-agent packets belong in Video Workbench and are not formal CCPE participant output. If this workflow is later packaged as deployable software, production/business agent implementation belongs in the target software project, not in Video Workbench.

View File

@ -0,0 +1,41 @@
# CCPE Consumption
This directory records how Video Workbench consumes CCPE from the outside.
The single default CCPE interface is:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
Before preparing any CCPE setup or invocation, read that file first. It routes consumers to:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-setup.md
```
## Rules
- Do not copy canonical CCPE prompts, agents, runtimes, model cards, protocols, or skills into this repository.
- Do not hardcode old Agent, Lite, Skill, Runtime, or protocol paths as default entrypoints.
- Read narrower CCPE artifacts only when `Interface.md`, the consumer setup contract, a project-local registry, or an active task requires them.
- Planned participants are not available until they have a real registry entry, readable `canonical_artifact_path`, invocation packet, real participant carrier, and returned output.
## Future Project-Local Invocation Shape
When a concrete Video Workbench project needs formal CCPE participant invocation, create the invocation contract inside that project, for example:
```text
projects/<project-id>/ccpe/
agent-registry.yaml
invocation-policy.md
invocations/
<participant-id>/
<run-id>/
agent-invocation-packet.md
prompt-to-send.md
returned-output.md
run-metadata.json
```
This path may be adjusted for the first real project, but the file roles must follow the CCPE consumer setup contract.

View File

@ -1,42 +0,0 @@
# CCPE Runtime Links
This file records how Video Workbench consumes CCPE System assets.
Canonical CCPE workspace:
```text
C:\Users\wangq\Documents\Codex\ccpe-system
```
## Planned Assets
| Asset | Type | Status | Notes |
| --- | --- | --- | --- |
| Qiangge's Apprentice | Lite / Agent Spec | planned | Primary dimensional output actor |
| Short Video Production Runtime | Runtime | planned | Full video package workflow |
| Source-To-Episode Splitter | Skill | planned | Split deep source into episodes |
| Angle Proposal Generator | Skill | planned | Generate three entry angles |
| Tone And Outline Builder | Skill | planned | Build video outline and global visual style |
| Storyboard Logic Builder | Skill | planned | Build timed storyboard logic |
| Shot Deep Production | Skill | planned | Build shot visual plan, prompt, voiceover, notes |
| Image Prompt Generator | Skill | planned | Produce consistent image prompts |
| Voiceover Script Generator | Skill | planned | Fit narration to duration budget |
| Publish Copy Generator | Skill | planned | Prepare platform copy |
## Policy
Do not copy canonical CCPE artifacts here. Record links, usage notes, and task-specific adapters only.
Video Workbench does not store canonical prompts, agent specs, model cards, or runtime specs. Missing CCPE capabilities should be requested through:
```text
requirements/ccpe/
```
Deterministic automation tools should be requested through:
```text
requirements/skills-vault/
```
Do not mark planned assets as executed or available until they have a real source path and validation record.

65
docs/cases/README.md Normal file
View File

@ -0,0 +1,65 @@
# Video Workbench Case Pattern Library
This directory is the local case-pattern library for Codex execution work in Video Workbench.
It is extracted from old GPT case files only at the level of structure, granularity, page or storyboard method, speaker-note style, visual asset layering, and review dimensions. It is not a prompt library and not a copy of the old GPT knowledge base.
## Source Basis
The first two patterns were localized from:
- `knowledge-vault/prompts/GPT/强哥的策划导演/30_CASE_典型视频分镜案例.md`
- `knowledge-vault/prompts/GPT/强哥的策划导演/31_CASE_典型培训AI_PPT案例.md`
Those source files remain historical GPT assets in Knowledge Vault. Video Workbench uses the extracted patterns below as Codex-side local execution guidance.
## Cases
| case | use when | local output focus |
| --- | --- | --- |
| [science-video-page-style-case.md](science-video-page-style-case.md) | Turning a deep article, model point, or public-facing concern into a PPT-style science video | Shot/page granularity, narration pacing, visual metaphor, review criteria |
| [training-ai-ppt-case.md](training-ai-ppt-case.md) | Turning AI education, method training, product enablement, or workshop content into a teachable slide deck | Teaching unit design, speaker notes, interaction, editable slide structure |
## Local Use
Use these cases after GPT V2 stage 0-5 planning has been accepted into a project `intake/` directory. Codex then converts the accepted planning into:
- `project.md` for project map and current focus;
- `execution-plan.md` for execution strategy, batch, round, and next decision;
- `visual-system/visual-system.md` for visual-system materialization and review;
- `slides/slides.md` and `slides/sNN/` for page or shot execution facts and assets.
## What To Extract
Extract these parts from old or future real cases:
- medium branch and audience;
- logic-to-page or logic-to-shot decomposition;
- page or shot function;
- one-unit-one-purpose granularity;
- editable page text vs visual asset vs narration or speaker notes;
- visual-system anchors and reusable motifs;
- review dimensions and acceptance criteria;
- batch/iteration advice.
## What Not To Inherit
Do not inherit these legacy assumptions:
- GPT outputs final image prompts.
- GPT outputs Codex JSON execution packages.
- GPT specifies local output paths, task lists, or generation parameters.
- the old assumption that every image prompt must forbid readable text.
- old source filenames or schemas become current Video Workbench contracts.
For current Video Workbench, text placement is an execution decision. Body copy is usually rendered in the editable PPT or video page layer; image-generated labels, formulas, diagrams, or text are allowed only when the execution plan and review criteria explicitly require that layer.
## Review Dimensions
When adding a new case pattern, check:
- Does the pattern state which medium branch it serves?
- Does it describe unit granularity without copying a full old case?
- Does it separate source logic, page or shot copy, visual assets, and narration/speaker notes?
- Does it provide review criteria that Codex can apply during small-batch iteration?
- Does it avoid old Prompt, JSON, path, and global text-rendering rules?

View File

@ -0,0 +1,440 @@
# 《在路上》项目从无到有到全量 slide 完成:文章素材文案
## 文档定位
- 类型:文章素材底稿 / case material。
- 用途:为未来写一篇关于 `video-workbench` 和《在路上》项目实践过程的文章提供素材、时间线、案例细节和可引用表述。
- 状态:素材草稿,不是工作流规则,不替代 `VIDEO_WORKBENCH.md`、`project.md`、`execution-plan.md` 或 `slides/slides.md`
- 项目路径:`projects/2026-06-23-在路上`。
- 当前项目状态:当前 51-shot 表的 shot-image production 已完成,项目进入 assembly / closeout 待启动阶段。
## 一句话主线
这个项目的关键,不只是“用 AI 生成了 51 个画面”,而是从一个还没有稳定形状的视频工作台开始,把一套 GPT 前期策划逐步压缩成本地可执行的项目骨架、视觉系统、参考图规则、slide 生产流水线、子会话协作机制和生产轻量化规则,最后完成了《在路上》当前 51-shot 表的全部图片生产。
更准确地说,它完成了两件事:
1. 《在路上》作为一个 MV / slide-image 项目,从策划文本变成了有视觉系统、有角色锚点、有 51 个画面单元、有完整图片产物的本地生产包。
2. `video-workbench` 作为一个工作台,从“需要摸索机制”演化成了“能用 production-light 直接批量生产,并靠 handoff / callback 可靠续跑”的工作流。
## 可直接放进文章的开场素材
一开始,`video-workbench` 并不是一个已经完全定型的生产系统。它更像一个本地工作间:有方向,有一些相邻仓库,有 GPT 输出的前期规划,也有 Codex 可以执行的本地文件系统,但真正的问题是,怎样把这些东西变成一个可持续生产的视频项目。
《在路上》就是这个工作台的第一个完整压力测试。
它不是从一张 prompt 开始的,也不是从“批量生成 51 张图”开始的。它从一组已经被接受的 GPT V2 策划材料开始MV 总纲、通用表达与视觉系统设计、人物锚点板说明、风格锚点板结构、51-shot 镜头骨架、核心单镜扩展。Codex 的任务不是再写一遍策划,而是把这些材料转成仓库能持续执行的控制文件。
这一步很关键。因为真正能把项目带到结尾的,不是更长的灵感文本,而是几个能被反复读取、被子会话继承、被任务记录续接的文件:`project.md`、`execution-plan.md`、`visual-system/visual-system.md` 和 `slides/slides.md`
从那一刻开始,《在路上》不再只是一个构想,而变成了一个本地生产项目。
## 阶段一:工作台先定边界
在项目早期,`video-workbench` 最先解决的不是图片,而是边界。
仓库被明确成一个“本地视频 / slide 执行工作台”,不是深度文章写作区,不是长期知识库,不是 CCPE canonical agent 存放地,也不是可复用自动化源码仓库。它和周边仓库的关系被切清楚:
- `knowledge-vault` 提供长期知识和来源材料。
- `writing-workbench` 负责深度文章生产。
- `ccpe-system` 提供正式 agent / runtime / model / interface。
- `skills-vault` 提供可复用自动化技能。
- `video-workbench` 只负责把已接受的策划和来源材料,落地成视频 / slide 项目的本地执行文件、素材、prompt、图片和 handoff。
这个边界后来非常重要。它避免了一个常见问题:把 GPT 的规划文本、Agent 机制、Prompt 模板、项目产物、工具源码全部塞进一个目录,最后谁也不知道哪个文件才是当前事实。
最终形成的规则是:真实项目都进入 `projects/<project-id>/`;项目状态写在文件里,不靠移动目录表达;跨阶段交接写在 `handoff/`;可复用能力缺失时写 supplier request而不是在项目里临时发明一套不可复用工具。
## 阶段二:从 GPT 策划到本地执行骨架
《在路上》的输入不是空白 prompt而是一批前期策划文件。Codex 先把它们安置在 `intake/`,再从中抽取本地执行骨架。
这一步形成了四个核心文件:
- `project.md`:项目地图,记录状态、阶段、已接受输入、核心方向、当前执行重点和下一步。
- `execution-plan.md`:执行控制文件,记录当前 medium branch、小批量策略、已完成轮次、当前默认生产路线。
- `visual-system/visual-system.md`:视觉系统权威文件,记录人物、风格、色光、构图、母题和关键镜头规则。
- `slides/slides.md`51-shot 的执行事实表,记录每个 `sNN` 单元的来源、功能、风格锚点、状态和产物。
这里有一个方法论转折GPT 策划不是被复制成新的“真相文件”而是被保留为来源。Codex 维护的是执行控制层。
这套骨架让项目有了长期可读性。后续无论主会话压缩、子会话切换、任务中断、图片失败、prompt 重试,都可以回到这几个文件上继续,而不是依赖某一段聊天记忆。
## 阶段三:视觉系统先于批量生产
《在路上》的视觉核心后来被凝练成一句话:
> 世界比人更大,路比人更长,人只是持续前行的坐标。
英文控制句是:
> World before face; road before pose; the traveler is a small coordinate that keeps moving.
这个规则决定了整个项目不是 portrait MV也不是旅行宣传片而是 landscape-led road documentary / poetic realism。
视觉系统被拆成几个稳定部件:
- 人物50 岁男性旅人,疲惫但没有垮掉,旧长外套、旧背包、旧靴子,形象要能持续走下去。
- 风格 A清晨泥泞旷野世界先于人出现。
- 风格 B高位观察和城市边缘表现系统压力。
- 风格 C泥泞里的星空低处看见宇宙是项目的灵魂画面。
- 风格 D夜路小火远方也有人在走但不是团聚、胜利或露营。
第一批真正重要的生产不是全量镜头,而是锚点验证:
- 人物锚点板 accepted。
- 从人物锚点板切出的透明人物切片 accepted。
- 风格锚点板 accepted。
- C 风格修复样本 accepted。
- 五个核心镜头 S-01、S-10、S-46、S-47、S-51 accepted。
这一步证明了项目的视觉方向:画面可以保持现实质感,也可以有诗性,但不能变成广告、英雄海报、赛博城市、魔法宇宙、露营团建或胜利结尾。
## 阶段四:第一次大问题不是审美,而是引用路径
项目早期曾经出现过一个关键问题: broad generation 的画面能出,但缺少可追溯的 per-shot prompt、真实参考图加载证据和稳定的身份控制。尤其是人物一致性场景不能靠文字描述去维持身份。
这促成了 S14 reference-capable generation investigation。
最后沉淀下来的规则是:
```text
gpt-image-2 Skill Advisor prompt/spec
-> 把真实参考图加载进对话可见上下文
-> 使用宿主 image_gen 生成
-> 把结果复制进项目目录
-> 在 prompt / handoff / slides.md 中记录参考角色和产物路径
```
这个结论非常重要。它把问题从“AI 能不能参考图片”转成了“项目文件怎样记录参考图片被如何使用”。也就是说,技术可行性不再反复争论,后续重点转向生产追踪和工作流清洁度。
从这里开始,`gpt-image-2` 在项目中承担的是 prompt/spec Advisor而不是默认 Garden / API 出图路径。身份关键画面必须加载真实参考图;在 prompt 里写本地路径只算 traceability不算真正加载。
## 阶段五:从单张试验到 slide task orchestration
为了让长生产可控,项目把每个画面、页面、镜头单元统一叫 `slide`。每个 slide 有自己的目录:
```text
slides/sNN/
sNN-vN-brief.md
sNN-vN-prompt.md
sNN-vN-image.png
sNN-vN-review.md # 只在 test/audit 或显式 review 时出现
```
这里又形成了一个重要原则append-only。
每次新执行都扫描已有 `sNN-v*-*` 文件,选择下一个未占用版本。旧版本即使失败,也保留为历史证据。默认 `Overwrite allowed: no`
这个规则不是形式主义。它是从实际失败里长出来的。早期有 broad-run 候选、覆盖缺陷、重复 worker、transport failure、 rejected image、incomplete evidence。只要允许“为了让目录好看而覆盖旧文件”项目历史就会被抹掉后续根本无法判断哪个 prompt 生成了哪个图,哪个失败被修复过,哪个版本是用户真正接受的。
所以最终形成的共识是:失败不是垃圾,失败是生产系统的一部分证据。
## 阶段六Agent 流程的试错
角色一致性阶段最早使用的是主会话、可见子会话和内部 one-shot slide Agent 的组合。
这个阶段产生了很多有效结果,也暴露了机制问题:
- S-05 单张试验证明了 reference-capable route 可以跑起来,但也留下了 overwrite defect 的历史记录。
- S-21、S-14、S-25 等画面视觉上被接受,但 S-14 出现了 duplicate worker 问题。
- session-04 处理 S-33 和 S-06形成更干净的 visible child session + one-shot SubAgent 模式。
- R4 处理 S-02、S-03、S-04 时,图片被接受,但 brief / packet ownership 出现偏差:文件由 slide Agent 写,而不是由 visible child session 预先拥有。
- R5 处理 S-07、S-08、S-09 时,修正了 brief ownership让成功输出在 worker 启动前已有 child-owned brief / packet。
这一段的意义在于:项目并不是一次设计出完美工作流,而是用实际画面生产暴露机制缺陷,再把缺陷转成规则。
早期的 Agent 并不是失败。它们帮助证明了 per-slide isolation、返回 receipt、reference role、review suppression、append-only retry 等机制。但当项目进入正式生产时,这套机制显得太重。
## 阶段七callback-only 和父子会话关系定型
长任务真正可持续,还需要解决一个上下文问题:主会话不能一直盯着子会话轮询,也不能把所有生产细节都塞回父线程。
R6 阶段把 callback-only 流程验证出来:
- 子会话完成所有允许的项目写入。
- 子会话更新 `slides/slides.md`
- 子会话写 compact `child-session-handoff.md`
- 子会话最后一步 callback 父会话。
- callback 后子会话不再写文件、不再检查项目。
这改变了主会话的职责。主会话不再是细节审计员,而是调度者和用户接口。它只需要读 callback 和 handoff 中的关键字段:
- status
- topology
- resolved versions
- image paths
- problems
- needs_user。
如果 clean completion没有问题父会话就不再打开 prompt、图片细节、return ledger 重新审一遍。
这一步对后来的批量生产非常关键。它把生产从“人盯着每个 worker 过程”变成“文件状态 + callback 驱动的可续跑流程”。
## 阶段八:从 test/audit 到 production-light
项目真正提速发生在 R7。
在 R7 之前,很多生产还围绕 Agent / packet / return / review / completion gate 展开。这适合 test/audit但不适合正式批量生产。
R7 的核心优化是 production-light
- normal production 由 clean child session 直接完成。
- 不默认启动 Agent / SubAgent。
- 不默认写 packet / return。
- 不默认写 review 文件。
- 不做 routine final audit。
- 保留必要的写入保护版本扫描、append-only、no overwrite、slides.md 更新、compact handoff、callback final action。
这个优化不是偷懒,而是把已经被证明的流程从“测试形态”压缩成“生产形态”。
session-12 先生成 S-26、S-27、S-28用户接受记录约 25m48s / 134K tokens。
session-13 再生成 S-29、S-30、S-31直接 child session、无 Agent/SubAgent用户接受记录约 10m32s / 114K tokens。
从 session-13 开始direct-child production-light 成为正式默认模型。
## 阶段九:容量验证
生产路线定型后,项目继续做容量验证,而不是立刻假设可以无限扩张。
先是 5-slide validation
- 范围S-32、S-34、S-35、S-36、S-37。
- topologydirect child。
- reviewnone。
- 结果:五张图被用户接受。
- 用户观察callback 时约 152K tokens / 58% context最终约 164K tokens / 63% context。
- 发现callback-order defect子会话在 callback 后仍做了部分文档 / 检查工作。
- 修正:未来 child prompt 必须明确 callback 是最终动作。
然后是 8-slide compression validation
- 范围S-38 到 S-45。
- topologydirect child。
- reviewnone。
- 结果8 张图进入 production-pass。
- 用户观察174K tokens / 67% context / 38m37s。
- 机制结果callback-final contract 被验证callback 后没有再观察到 child project writes 或 checks。
这一步把普通 production-light 子会话容量提升到最多 8 个 ordinary slides同时保留降级规则身份重、修复重、核心风险高或上下文昂贵的任务仍然用 1 到 3 个 slide。
## 阶段十:最后一包 S48-S50 收口
最后的默认生产范围只剩 S-48、S-49、S-50。
这一包已经不再是工作流发明,也不是机制辩论。它按已经定型的 production-light route 直接执行:
- direct child session
- no Agent/SubAgent
- review mode none
- 写 brief、prompt、image
- 更新 `slides/slides.md`
- 写 `child-session-handoff.md`
- callback 父会话作为最终动作。
最终记录:
- S-48 -> `s48-v1-image.png`
- S-49 -> `s49-v1-image.png`
- S-50 -> `s50-v1-image.png`
- child reported `complete`
- `problems: none`
- `needs_user: none`
- parent verification found expected files present, review files absent, slide rows updated, and no post-callback child writes。
到这里,当前 51-shot 表的 shot-image production 完成。项目状态进入 assembly-closeout。
## 素材时间线
### 0. 工作台定位期
- 明确 `video-workbench` 是本地视频 / slide 执行工作台。
- 确立 `projects/` 为唯一真实项目根。
- 确立 `project.md`、`execution-plan.md`、`visual-system/`、`slides/`、`tasks/` 的职责。
- 确立 GPT / User / Codex 分工。
### 1. 《在路上》项目初始化
- 接收 GPT V2 前期策划文件。
- 清理 intake。
- 提取四文件执行骨架。
- 建立 51-shot `slides/slides.md` 事实表。
- 确立核心视觉方向landscape-led road documentary / restrained poetic realism。
### 2. 视觉锚点建立
- 人物锚点板 accepted。
- 透明人物切片 accepted。
- A/B/C/D 风格锚点建立。
- C 风格修复 accepted。
- 五个 anchor-test shots acceptedS-01、S-10、S-46、S-47、S-51。
### 3. 参考图机制证明
- S14 investigation 证明 host visible-context reference path 可用。
- 项目规则更新为 `gpt-image-2 Advisor + loaded reference image + host image_gen`
- identity-critical shots 不允许 text-only 身份生成。
### 4. 角色一致性和 per-slide traceability
- 从 S-05、S-21、S-14、S-25、S-33 等试验开始。
- 发现并记录 overwrite、duplicate worker、brief ownership、transport failure 等问题。
- 固化 append-only、no overwrite、one-shot worker、review suppression、visible-reference evidence 等规则。
### 5. callback-only 定型
- 子会话完成写入和 handoff 后 callback 父会话。
- 父会话不再 routine polling。
- clean callback 后父会话只消费 compact handoff。
### 6. production-light 定型
- session-12S-26、S-27、S-28 accepted。
- session-13S-29、S-30、S-31 direct-child accepted。
- direct-child, no-Agent, review none 成为正式生产默认路线。
### 7. 容量验证
- 5-slide validationS-32、S-34、S-35、S-36、S-37 accepted发现 callback-order defect。
- 8-slide validationS-38 到 S-45 production-pass验证 callback-final contract。
- 默认 ordinary package size 提升到最多 8 slides。
### 8. 完成当前 51-shot 表
- final packageS-48、S-49、S-50 complete。
- 当前 51-shot shot-image production complete。
- 下一阶段转入 assembly / export / closeout。
## 可以支撑文章的几个观点
### 观点一AI 生产不是 prompt 工程,而是本地执行系统工程
《在路上》不是靠一条万能 prompt 完成的。它靠的是文件结构、版本策略、参考图规则、子会话边界、callback、handoff 和生产线轻量化。
Prompt 很重要,但 prompt 只有在能被追溯、能被续跑、能和参考图 / 版本 / 输出路径绑定时,才真正成为生产资产。
### 观点二:失败记录比成功截图更有价值
项目里保留了 rejected image、incomplete evidence、transport failure、duplicate worker、sequencing warning、callback-order defect。它们没有被清掉而是被转化为规则。
这些失败让系统知道:
- 不能覆盖旧文件;
- 不能把 text-only 当身份参考;
- 不能让 worker 抢写 brief
- 不能 callback 后继续写文件;
- 不能每次都重开完整 audit。
### 观点三:正式生产不是更复杂,而是把复杂度收回去
早期 `test/audit` 需要 Agent、packet、return、review、completion gate。它适合发现问题。
但正式生产阶段,复杂度必须被压缩。`production-light` 的价值就是在保留必要安全线的前提下,去掉 routine review、routine audit、packet / return 和默认 Agent把生产变成 direct-child package。
这不是降低标准,而是把“已经证明过的标准”变成更低成本的执行方式。
### 观点四:长任务续跑靠文件,不靠记忆
`project.md``production-run-status.md`,从 `slides/slides.md``child-session-handoff.md`,整个项目不断把聊天过程固化为可读文件。
这使得主会话压缩、子会话切换、上下文中断都不再是灾难。下一轮只要按 load order 读文件,就能继续。
### 观点五:人的角色不是每张图都 review而是决定何时相信生产线
`production-light` 阶段,用户不再逐张 image review。用户做的是更高层的判断
- 核心路线是否成立;
- 哪些包可以进入 production-pass
- 默认生产容量能不能从 3 张提升到 5 张、再到 8 张;
- 什么时候停止生产,转入 assembly / closeout。
这改变了人机协作的焦点:人不是流水线质检员,而是生产路线的 owner。
## 可引用句子
- 《在路上》的完成,不是“生成 51 张图”的故事,而是“把一个不稳定的 AI 生产现场,逐步压成可续跑生产线”的故事。
- GPT 给了方向Codex 把方向变成文件系统里的执行秩序。
- 真正让项目继续下去的,不是某一次聊天记忆,而是 `project.md`、`execution-plan.md`、`slides.md` 和 handoff。
- 失败没有被抹掉。失败被留在版本里,变成下一条规则。
- 从 test/audit 到 production-light核心变化不是更大胆而是更克制。
- 生产线成熟的标志,不是记录越来越多,而是知道哪些记录可以不写。
- 当 callback 成为子会话的最后动作,长任务才真正从“盯进度”变成了“等状态”。
- 人不必 review 每张图,但必须决定什么时候一条路线已经值得信任。
- 这个项目的经验是AI 创作要规模化,必须先把创作过程变成可追溯的本地工程。
## 文章可展开的结构建议
### 写法 A项目复盘型
1. 开头:为什么不是 prompt 成功,而是工作流成功。
2. 第一部分:`video-workbench` 为什么要先定边界。
3. 第二部分:《在路上》如何从 GPT 策划变成四文件执行骨架。
4. 第三部分:视觉系统如何用 A/B/C/D 和人物锚点稳定下来。
5. 第四部分reference-capable generation 为什么是关键转折。
6. 第五部分:从 Agent-heavy 到 production-light 的演化。
7. 第六部分:容量验证和全量完成。
8. 结尾AI 视频生产的真正对象,是“可续跑生产线”。
### 写法 B方法论型
1. 输入不是 prompt是 accepted intake。
2. 输出不是图片,是 append-only project state。
3. 审美不是感觉,是 visual-system rule。
4. 失败不是删掉,是版本化。
5. 协作不是等人盯,是 callback。
6. 批量不是并行,而是轻量生产线。
### 写法 C人机协作型
1. GPT 负责想象和策划。
2. 用户负责决定与接受。
3. Codex 负责本地化、执行、记录和续跑。
4. 子会话负责小批量生产。
5. 文件系统负责记忆。
6. 最后形成的不是一个 prompt而是一套可被复用的生产经验。
## 关键证据路径
项目状态与结论:
- `projects/2026-06-23-在路上/project.md`
- `projects/2026-06-23-在路上/execution-plan.md`
- `projects/2026-06-23-在路上/slides/slides.md`
- `handoff/2026-06-25-on-the-road-formal-production-handoff.md`
视觉系统:
- `projects/2026-06-23-在路上/visual-system/visual-system.md`
- `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md`
- `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
工作流规则:
- `VIDEO_WORKBENCH.md`
- `docs/workflows/project-lifecycle.md`
- `docs/workflows/slide-task-orchestration.md`
- `docs/workflows/slide-task-templates.md`
关键 handoff
- `handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md`
- `handoff/2026-06-24-character-consistency-r6-notification-s16-handoff.md`
- `handoff/2026-06-25-on-the-road-formal-production-handoff.md`
后期生产任务:
- `projects/2026-06-23-在路上/tasks/2026-06-25-production-capacity-validation/production-run-status.md`
- `projects/2026-06-23-在路上/tasks/2026-06-25-8slide-compression-validation/production-run-status.md`
- `projects/2026-06-23-在路上/tasks/2026-06-25-final-production-s48-s50/production-run-status.md`
## 待补充素材
这些内容如果未来写正式文章,建议再补:
- 选几张关键图片作为插图人物锚点板、C 修复样本、S-16 rejected / accepted 对照、8-slide validation 中的一组连续画面。
- 补一段用户视角:为什么《在路上》的主题需要“世界先于人”。
- 补一段操作截图或目录截图:展示 `slides/sNN/sNN-vN-*` 的 append-only 结构。
- 如果文章面向工程读者,可加入 callback-only 子会话流程图。
- 如果文章面向创作者,可弱化 Agent / token 细节,强化“从灵感到生产线”的叙事。

View File

@ -0,0 +1,156 @@
# Science Video Page-Style Case Pattern
This pattern is for PPT-style science videos: a deep article or model is reduced into a short public-facing video made of page-like shots, narration, and visual assets.
It is extracted from the old `30_CASE` video storyboard case. The original topic, prompts, Codex JSON, output paths, and global text prohibitions are not carried forward.
## Use When
Use this pattern when the target is:
- a 3-10 minute public-facing science, cognition, AI, product-thinking, or method-explainer video;
- a PPT-style video with page/shot images plus narration;
- a video that explains a mechanism, risk, contradiction, method, or model through metaphors and staged visual pages;
- not a drama short, not a full video-editing workflow, and not a character-continuity MV.
## Core Pattern
```text
source point
-> public-facing concern
-> controlling metaphor
-> video outline
-> shot/page list
-> shot/page deep spec
-> narration
-> visual asset brief
-> review and iteration
```
The case value is not the original topic. The reusable method is "page-style explanation": each shot behaves like a compact visual argument, not like a literal filmed scene.
## Granularity
Default unit size:
- 6-10 units for a short explainer;
- 25-70 seconds per unit;
- about 90-260 Chinese characters per unit;
- one unit carries one logic function;
- one high-density method unit may be longer, but it still needs one clear governing frame.
Common unit functions:
| function | purpose |
| --- | --- |
| hook | create urgency or recognisable public concern |
| story anchor | give the viewer a concrete person, situation, or conflict |
| controlling metaphor | make the whole mechanism memorable |
| mechanism reveal | explain the hidden process or failure mode |
| practical frame | turn the concept into methods, checks, or choices |
| closing elevation | return to the larger judgment or changed mental model |
## Local Unit Spec
For Video Workbench, put this in `slides/sNN/sNN-unit-spec.md` or use it as the basis for that file:
| field | purpose |
| --- | --- |
| `unit_id` | `sNN` identifier used by local files |
| `source_anchor` | source paragraph, GPT V2 stage-5 row, or accepted intake note |
| `narrative_function` | hook, story anchor, metaphor, mechanism, method, or closing |
| `core_message` | one sentence the viewer should retain |
| `page_copy` | short overlay text or subtitle-layer copy, if needed |
| `voiceover_intent` | what narration must explain beyond page copy |
| `visual_task` | what the visual asset must make visible |
| `asset_layers` | background, metaphor object, human element, diagram, overlay, audio |
| `continuity_link` | how this unit connects to the previous and next unit |
| `review_focus` | the two or three things to inspect first in iteration |
This is a local execution spec, not a final image prompt. Final prompt files remain Codex-owned `sNN-vN-prompt.md` artifacts when image generation is actually performed.
## Page And Asset Layering
Separate layers before prompting or generating images:
| layer | owns |
| --- | --- |
| source logic | the concept, contradiction, risk, or method from accepted input |
| page text | the few words that may be rendered by PPT/video page layer |
| visual asset | metaphor scene, background, figures, diagram base, mood, composition |
| narration | full explanation, transition, examples, and punchline |
| review notes | whether the visual asset really carries the logic |
Do not treat "image contains no readable text" as a global rule. Decide per unit:
- If text must be editable or frequently revised, keep it in the PPT/video page layer.
- If labels, formulas, UI snippets, or diagram words are essential to the visual explanation, allow them only with explicit review criteria.
- If the image model is likely to garble precise wording, keep precise wording outside the generated image.
## Shot/Page Design Method
For each unit, answer in this order:
1. What is the viewer supposed to understand or feel at this moment?
2. What is the simplest visible metaphor or situation that makes it concrete?
3. What page text is useful, if any?
4. What must narration explain that the image should not carry alone?
5. Which part of the unit is high risk: logic, metaphor, composition, text placement, or visual generation?
6. What would make the unit fail review?
The visual should not decorate the narration. It should do at least one of these jobs:
- compress an abstract mechanism;
- expose a contradiction;
- make a risk feel real;
- separate similar concepts;
- hold attention while narration explains a dense idea;
- signal a transition in the argument.
## Review Dimensions
Review generated or drafted units against these dimensions:
| dimension | pass condition |
| --- | --- |
| logic clarity | one unit maps to one clear logic point |
| metaphor fit | the metaphor explains the point instead of becoming a side joke |
| public accessibility | a non-specialist can understand the visible situation |
| narration fit | voiceover adds explanation, not redundant caption reading |
| composition | image leaves safe space for page text if page text is planned |
| asset feasibility | the image can be generated or assembled without fragile exact text |
| continuity | the unit advances from the previous one and sets up the next one |
| medium fit | it remains a science/explainer page, not an accidental drama scene |
## Small-Batch Strategy
Do not generate every unit first. Pick representative high-risk units:
- one hook or opening unit;
- one controlling-metaphor unit;
- one mechanism-explanation unit;
- one practical-method or dense information unit;
- one closing or elevation unit when tone is uncertain.
Record the selected batch in `execution-plan.md`, then track unit-level facts in `slides/slides.md`.
## Abstracted Example Shape
```md
## s03 Unit Spec
- narrative_function: controlling metaphor
- core_message: The tool is useful only when matched to the weight of the real-world problem.
- page_copy: two short lines, rendered outside the generated image unless the execution plan says otherwise
- voiceover_intent: contrast everyday low-risk use with high-stakes decision use
- visual_task: make the mismatch between lightweight confidence and large external risk visible
- asset_layers:
- background: large-scale risk environment
- metaphor object: small helpful tool that looks insufficient at scale
- human element: ordinary user facing the environment
- overlay: optional page text layer
- review_focus:
- risk scale is obvious
- metaphor does not become comic noise
- composition supports 16:9 page use
```

View File

@ -0,0 +1,162 @@
# Training AI PPT Case Pattern
This pattern is for training, AI education, customer enablement, internal workshops, and method lectures that need a teachable slide deck.
It is extracted from the old `31_CASE` training AI PPT case. The original topic, prompts, Codex JSON, output paths, and global text prohibitions are not carried forward.
## Use When
Use this pattern when the target is:
- a training deck, course deck, lecture deck, workshop deck, or AI education PPT;
- a slide sequence that must support live explanation, pause, discussion, and later reuse;
- a deck where each page is a teaching unit, not a video shot;
- not a customer proposal whose primary goal is decision conversion.
## Core Difference
Training PPT pages are not scenes. They are teachable units.
Each page should answer:
- What should the learner understand after this page?
- What misconception or resistance might exist before this page?
- What example, analogy, contrast, diagram, or exercise lowers the learning barrier?
- What can the learner do, judge, or remember after this page?
## Learning Path
Common sequence:
```text
problem entry
-> concept or model
-> method frame
-> example or contrast
-> practice or migration
-> summary and action
```
Not every deck needs all six parts, but the page order should behave like a learning path rather than a list of impressive points.
## Page Granularity
Default rule:
- one page solves one teaching goal;
- slide copy stays sparse and editable;
- speaker notes carry explanation, examples, and transition;
- interaction is included when the page benefits from learner reflection;
- abstract models need a diagram, matrix, loop, ladder, map, or other visible structure.
Avoid one page trying to explain a concept, prove a case, give a method, run an exercise, and conclude the section at the same time.
## Local Page Spec
For Video Workbench, put this in `slides/sNN/sNN-unit-spec.md` or use it as the basis for that file:
| field | purpose |
| --- | --- |
| `unit_id` | `sNN` identifier used by local files |
| `slide_role` | opening, concept, model, contrast, case, practice, summary, transition |
| `teaching_goal` | what the learner should understand, change, or be able to do |
| `core_message` | one sentence that gives the page its point |
| `slide_copy` | editable title, subtitle, bullets, labels, or quoted line |
| `layout` | comparison, triangle, matrix, timeline, loop, ladder, map, flow, dashboard |
| `visual_asset_brief` | background, metaphor, concept visual, diagram base, or scene asset |
| `speaker_notes` | how the instructor explains the page |
| `interaction` | question, quick vote, reflection, mini exercise, or none |
| `transition` | how this page connects to adjacent pages |
| `review_focus` | what Codex should inspect during iteration |
This is a local execution spec, not a final image prompt or JSON execution package.
## Slide And Asset Layering
Keep these layers separate:
| layer | owns |
| --- | --- |
| editable slide text | titles, subtitles, bullet points, labels, formulas, exact wording |
| layout | structure that controls learner attention |
| visual asset | background, metaphor scene, illustration, diagram base, icons, texture |
| speaker notes | explanation, example, pacing, transition, instructor emphasis |
| interaction | question or exercise that turns listening into retrieval or judgment |
Generated images should not be asked to carry precise deck body copy by default. If the design needs diagram labels or visible text inside an image, document that choice in `execution-plan.md` or the unit review criteria.
## Speaker Notes Style
Speaker notes should do three jobs:
- explain the key concept in plain language;
- give a concrete life, classroom, business, or product example;
- bridge to the next page.
Good notes are not page copy repeated aloud. They let the slide stay sparse while still giving the instructor enough material to speak for 1-2 minutes when needed.
## Common Page Patterns
| pattern | use when | layout hint |
| --- | --- | --- |
| structural problem | establish why the topic matters | triangle, tension map, before/after |
| misconception correction | replace a shallow belief with a better frame | split screen, false/true contrast |
| model introduction | name and explain a reusable model | matrix, loop, layered diagram |
| method frame | turn concept into steps or checks | flow, ladder, checklist, flywheel |
| case comparison | show how AI changes a task or judgment | traditional vs AI-enabled |
| practice page | make learners apply the frame | prompt, scenario, quick exercise |
| summary chain | close the logic path | timeline, chain, staircase, map |
"Traditional vs AI-enabled" is especially useful for AI training case pages, but it is a pattern choice, not a global rule.
## Review Dimensions
Review drafted or generated pages against these dimensions:
| dimension | pass condition |
| --- | --- |
| teaching goal | one page has one clear learner outcome |
| copy density | slide text is sparse enough to scan and edit |
| layout clarity | structure helps understanding rather than decorating the page |
| speaker notes | notes explain, exemplify, and transition |
| asset layering | visual assets do not replace editable slide text by accident |
| interaction | any question or exercise has a clear teaching reason |
| sequence | the page advances the learning path |
| live usability | an instructor can pause on the page and teach from it |
## Small-Batch Strategy
Do not build the full deck visually before validating the teaching system. Pick representative pages:
- one opening or problem page;
- one abstract model page;
- one method-frame page;
- one case-comparison page;
- one practice or summary page if interaction or closing tone is uncertain.
Record the selected batch in `execution-plan.md`, then track page-level status in `slides/slides.md`.
## Abstracted Example Shape
```md
## s08 Unit Spec
- slide_role: model introduction
- teaching_goal: Learners understand that the model is a decision aid, not a decorative framework.
- core_message: A usable model changes what people can notice, compare, and improve.
- slide_copy:
- title: short model name
- subtitle: one-line use claim
- bullets: three editable labels or dimensions
- layout: center matrix with one highlighted region
- visual_asset_brief: clean diagram base with subtle learning-path motion; exact labels remain editable in the slide layer
- speaker_notes:
- define the model in plain language
- give one concrete classroom or work example
- explain why the next page moves from model to use case
- interaction: ask learners which dimension they currently under-observe
- review_focus:
- model structure is legible
- page is not crowded
- notes can support live explanation
```

View File

@ -1,12 +1,26 @@
# CCPE System Handoff For Video Workbench
This document is the handoff for future work in:
This document is the handoff for future supplier work in:
```text
C:\Users\wangq\Documents\Codex\ccpe-system
```
It records the CCPE assets needed to support Video Workbench.
It records candidate CCPE assets needed to support Video Workbench. It is not the CCPE consumer interface and must not be used as a formal invocation startup path.
The external CCPE interface is:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
For any CCPE setup or invocation, read `Interface.md` first, then follow it to:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-setup.md
```
Do not treat the candidate paths below as canonical invocation paths until a project-local registry resolves a participant to a real `canonical_artifact_path`.
## Core Principle
@ -22,11 +36,7 @@ Previous single-agent actor:
强哥的徒弟
```
Likely first target:
```text
agents/lite/qiangge-apprentice.prompt.md
```
Likely first supplier target: a CCPE-owned Lite artifact or Agent Spec for the dimensional-output actor. Do not record a concrete `canonical_artifact_path` here; that belongs in the project-local registry when a real invocation is prepared.
Purpose:
@ -34,7 +44,7 @@ Purpose:
Transform deep essays and models into public-facing short video plans, scripts, visual prompts, and production packages.
```
This actor should remain a CCPE-owned local work asset. Video Workbench may request, consume, and validate it, but should not store its canonical prompt or agent definition.
This actor should remain a CCPE-owned local work asset. Video Workbench may request, consume, and validate it, but should not store its canonical prompt or agent definition. Formal use must go through the CCPE interface and project-local registry rules.
## Recommended CCPE Build Sequence

View File

@ -1,23 +1,108 @@
# Video Workbench Context Handoff
This document preserves the working agreements for Video Workbench so future Codex sessions do not depend on copied chat history.
This document preserves the current working agreements for Video Workbench so future Codex sessions do not depend on copied chat history.
## Confirmed Architecture
```text
Knowledge Vault = source archive and model/essay library
Writing Workbench = deep article production workspace
Video Workbench = public-facing dimensional video output workspace
CCPE System = actor, skill, model, and runtime factory
Video Workbench = local video/slide execution workspace
CCPE System = actor, skill, model, runtime, and interface supplier
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 video production 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.
## User's Dimensional Output Workflow
## Collaboration Contract
The user's deep essays are often 7,000 to 50,000 Chinese characters. Direct decompression into public form can multiply the text volume, which does not fit current public reading habits.
```text
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, Remotion implementation, visual-system materialization, iteration, generated assets
```
Most planning files should come from GPT output accepted by the user and placed in `projects/<project>/intake/`. Codex-maintained files should be local execution aids and execution records.
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
Use one project root:
```text
projects/<project-id>/
```
Do not move projects between status folders. Record status in `project.md`.
Do not decide series vs standalone through directory placement. Record series membership in `project.md`; add `projects/_series/` only when a real series needs shared files or an index.
Recommended project-local structure:
```text
projects/<project-id>/
project.md
intake/
execution-plan.md
visual-system/
visual-system.md
refs/
iterations/
remotion/
package.json
src/
public/
slides/
slides.md
s01/
s02/
```
Use root `handoff/` for repo-level, cross-project, series-level, or context-window handoff notes.
Use `docs/cases/` as the local Codex case-pattern library. It is allowed to extract structure, page or shot granularity, speaker-note style, visual asset layering, and review dimensions from old GPT cases, but it must not re-import old final-prompt, Codex JSON, output-path, or global text-rendering rules.
## Project Files
`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 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, 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
Use `investigations/` for research reports, experiments, comparisons, draft workflow proposals, and reviewable evidence.
`tmp/` is deprecated. New durable investigation material should go under `investigations/`; short-lived scratch material should be deleted when no longer needed.
`garden-gpt-image-2/` remains reserved for tool-level image prompt or workflow traces when that path is used.
## Text Encoding
All local Markdown, JSON, YAML, text, prompt, discussion, and handoff files are UTF-8 unless a file explicitly declares another encoding.
Use explicit UTF-8 when reading these files from PowerShell:
```powershell
Get-Content -LiteralPath <path> -Encoding UTF8
Select-String -Path <path> -Pattern <pattern> -Encoding UTF8
```
## Dimensional Output Rule
The user's method:
@ -28,123 +113,11 @@ Produce a video usually under 10 minutes.
Use about 220 Chinese characters per minute as the narration budget.
```
The previous single-agent actor was named `强哥的徒弟`. Video Workbench should preserve the workflow but move toward file-based, agentic production.
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/<project>/remotion/`, and the default deliverable is source code plus a renderable MP4.
## Workflow Stages
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.
### Stage 0: Series Architecture
Decide whether the video belongs to a series or is standalone.
Inputs usually include:
- `knowledge-vault/rules` model documents
- `knowledge-vault/sayings` essay originals
- selected source material
Outputs:
- series plan, if any
- episode split
- target duration
- word budget
- selected source map
### Stage 1: Angle Proposals
Find three distinct entry angles.
Output style:
```text
EP.01 [temporary episode name] - angle proposal
```
The user selects the angle.
### Stage 2: Tone And Outline
Produce the video outline:
- framing and positioning
- core thought anchor
- governing metaphor
- global visual style constraints
- Chinese style description
- English Global Prompt parameters
- narration/writing protocol
### Stage 3: Storyboard Logic
Produce storyboard logic with time and word budget.
Example:
```text
Shot 1 [Puzzle Introduction]: 30 seconds / about 110 Chinese characters.
Shot 2 [Deep Dive]: 90 seconds / about 330 Chinese characters.
```
### Stage 4: Shot Deep Production
For each shot, produce:
- page or screen visual plan
- image generation prompt
- voiceover script
- design subtext
- transition notes
### Stage 5: Assets
Generate or collect:
- images
- voiceover audio
- optional video clips
- asset log
Image and audio generation can be automated later. Image-to-video remains manual for now.
### Stage 6: Editing
Editing remains manual initially.
Video Workbench should provide edit notes and timeline plan, not assume full editing automation.
### Stage 7: Publishing
Publishing remains manual initially.
Video Workbench can prepare platform copy:
- title options
- description
- cover copy
- hashtags / tags
- final script
## Project Shape
Use `series/` for multi-episode work and `standalone/` for one-off videos.
Each episode should preserve both process and final outputs. The canonical expanded episode structure is in:
```text
templates/episode-project/EPISODE_STRUCTURE.md
```
## Two Modes
### Execution Mode
Use existing sources, files, CCPE assets, and automation skills to complete work for the current video package.
Execution mode may prepare source maps, angle proposals, selected angle records, outlines, storyboards, shot-level production files, voiceover scripts, image prompts, asset logs, editing checklists, publishing copy, status records, and user decision records.
Execution mode must not invent missing formal agent output or treat planned capabilities as executed.
### Capability-Request Mode
## Capability-Request Mode
When an agent, skill, runtime, model card, invocation protocol, or deterministic automation tool is missing, create a supplier ticket and pause the dependent part of the work.
@ -157,6 +130,14 @@ requirements/skills-vault/
CCPE supplies local work agents, runtime rules, model cards, invocation contracts, governed cognitive assets, and external capability registrations.
The single CCPE external interface is:
```text
C:\Users\wangq\Documents\Codex\ccpe-system\Interface.md
```
Read that file first, then follow it to the consumer setup contract. Do not use older Agent, Lite, Skill, Runtime, or protocol paths as default startup paths.
Skills-vault supplies deterministic automation tools, scripts, batch utilities, exporters, and installable automation skills.
## New Session Instruction
@ -164,5 +145,5 @@ Skills-vault supplies deterministic automation tools, scripts, batch utilities,
Use this in a new Video Workbench session:
```md
Please read README.md, VIDEO_WORKBENCH.md, docs/context-handoff.md, and docs/ccpe-system-handoff.md first, then continue work on Video Workbench according to those conventions.
Please read AGENTS.md, README.md, VIDEO_WORKBENCH.md, docs/context-handoff.md, and docs/ccpe-system-handoff.md first, then continue work on Video Workbench according to those conventions.
```

View File

@ -0,0 +1,108 @@
# Project Lifecycle
## Status
- Status: active global workflow rule.
- Scope: all `video-workbench` projects, regardless of whether the final artifact is an MV, explainer video, slide-style presentation, or another visual/video package.
This document defines the common lifecycle. Project-specific files decide what each phase means for that medium.
## Lifecycle Phases
Use these phases in `projects/<project>/project.md`:
| Phase | Meaning | Common exit condition |
| --- | --- | --- |
| `intake-cleanup` | Accepted GPT / user source material is repaired, normalized, and stored under `intake/`. | Source files are readable, named, and mapped to local execution roles. |
| `system-definition` | Source material is localized into project production systems. | Local control files and production authorities exist. |
| `pilot-validation` | Core units, risky visual/audio rules, and workflow mechanics are tested. | The user accepts the core route and authorizes production. |
| `production` | Units are produced in batches through the approved route. | All target units are complete, accepted or explicitly deferred, and no active production package remains. |
| `assembly-closeout` | Produced assets are assembled, exported, reviewed for final use, and archived. | Delivery/output artifacts and handoff records are complete. |
The lifecycle phase is not the same as the operating line. A project in `production` can still temporarily use `test/audit` for a repair or failure investigation. A normal production package should use `production-light` after the route is approved.
## Medium-Specific Outputs
The phase names stay stable; the concrete work differs by medium.
| Medium | `system-definition` examples | `pilot-validation` examples | `production` examples |
| --- | --- | --- | --- |
| 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/<project>/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/`, `remotion/` when applicable, and medium-specific control files.
## Production Run State
For any production request that may continue across multiple child sessions, create or update a lightweight run state file:
```text
projects/<project>/tasks/<task-id>/production-run-status.md
```
This file is the compression-safe continuation surface for unattended production. It should be short and current, not an audit report.
It records:
- project path;
- lifecycle phase;
- 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;
- latest callback summary.
The parent session may be automatically compressed. After each child callback, the parent should reload the minimal source of truth before dispatching the next package:
```text
AGENTS.md
VIDEO_WORKBENCH.md
docs/workflows/project-lifecycle.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
projects/<project>/project.md
projects/<project>/execution-plan.md
projects/<project>/visual-system/visual-system.md
projects/<project>/slides/slides.md
projects/<project>/tasks/<task-id>/production-run-status.md
projects/<project>/tasks/<task-id>/task-log.md
```
Only read detailed prompts, images, old session records, or prior handoffs when the current handoff reports `blocked`, `failed`, `warning`, collision, ambiguous scope/status, or the user explicitly asks for inspection.
## Unattended Production Loop
When the user authorizes a full production run:
1. Resolve the target set from the project fact table.
2. Write `production-run-status.md` and `task-log.md`.
3. Dispatch exactly one clean child session for the next package.
4. Stop routine parent polling and wait for callback.
5. The child completes all artifact writes, `slides/slides.md` updates, compact closeout checks, and `child-session-handoff.md` before callback.
6. The callback is the child's final action. The child must not write or verify additional project files after a successful callback.
7. On callback, the parent reads the child handoff and updates the run state.
8. If status is clean and target units remain, dispatch the next package.
9. Stop only when the target set is complete or a stop condition is reached.
The parent does not need exact token/context usage to continue. It relies on file-backed reload after callback. A separate successor orchestration session is a fallback, not the default, and should be used only when the current parent cannot continue cleanly.
## Stop Conditions
Stop and ask the user when:
- a requested scope cannot be mapped cleanly;
- a package would include an already accepted unit unless explicitly requested;
- a target output path already exists and overwrite was not authorized;
- required references or production authority files cannot be loaded;
- child callback reports `blocked`, `failed`, or `warning`;
- user confirmation is explicitly required for the validation package result;
- the next action would change global package-size defaults or lifecycle rules.

View File

@ -0,0 +1,698 @@
# Slide Task Orchestration Plan
## Status
- Draft date: 2026-06-24.
- Scope: local Video Workbench slide-production orchestration.
- Status: approved implementation basis.
- Project driver: `projects/2026-06-23-在路上`.
This plan is not a CCPE workflow. It is a local Video Workbench execution protocol for reducing main-session context pressure while keeping slide production traceable and lightweight.
Active workflow docs created from this plan:
```text
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
```
## Core Principles
1. Keep the workflow practical.
- This is not a software development project and should not become a heavy governance system.
- Record only the minimum task evidence needed for continuation, debugging, and user review.
2. Protect user attention.
- The user and any expert reviewer should not inspect every non-core slide.
- User review is reserved for run authorization, core slides, high-risk slides, failed slides, and explicit sampling.
3. Keep context bounded.
- The main session should not carry every slide's full prompt, generation, and review context.
- Child sessions reuse common project context for a small number of slides.
- One slide agent handles exactly one slide.
4. Avoid session contamination.
- No parallel child sessions by default.
- No multi-slide agents.
- Batch grouping happens at the session level, not inside a slide agent.
5. Keep files as the continuation source.
- Chat history is not authoritative after compression.
- Briefs, prompts, images, returns, logs, and handoffs must be written to disk.
6. Treat `visual-system/` as the production authority.
- slide work must use the active visual-system files rather than reconstructing style or character rules from memory.
- Style continuity comes from `visual-system/style/style-prompt-master.md` and its active style reference rules.
- Character continuity comes from `visual-system/characters/character-reference-registry.md` and active character reference images.
- When a slide contains a visible character and identity matters, text-only prompting is not sufficient.
7. Use the `gpt-image-2` Skill Advisor workflow for prompt work.
- slide prompts must be produced through the `gpt-image-2` Skill workflow.
- In the current default path, use Advisor / host-native mode: render the prompt/spec with the Skill, then use the host image tool only when the task allows generation.
- Do not freehand final project-bound image prompts from the brief alone.
## Orchestration Model
```text
main orchestration session
-> task plan
-> child session 01
-> write brief for s05
-> start slide agent for s05
-> write brief for s21
-> start slide agent for s21
-> write brief for s14
-> start slide agent for s14
-> write child-session handoff
-> child session 02
-> write brief for s25
-> start slide agent for s25
-> write brief for s33
-> start slide agent for s33
-> write child-session handoff
```
Default child-session capacity:
- 3 slides maximum per child session.
- Fewer slides are allowed when the slides are identity-heavy, repair-heavy, or otherwise context-expensive.
- Child sessions run sequentially, not in parallel.
Default slide-agent capacity:
- 1 slide per agent invocation.
- The slide agent must not accept a range or batch of slides.
## Worker Profiles
This plan implements only the current worker profile:
```text
video-slide-production
```
Current profile behavior:
- uses project `visual-system/` as the production authority;
- uses `slides/` as the slide artifact area;
- uses `gpt-image-2` Skill Advisor / host-native prompt workflow;
- uses style prompt master and active character reference registry;
- has no extra project knowledge base by default.
Reserved future profile:
```text
ppt-page-production
```
Future profile notes:
- may use `docs/cases/` as an additional case-pattern knowledge base;
- may need page-level brief, prompt, and review structures rather than slide-level structures;
- must not inherit video-slide rules blindly;
- should be designed when the first real PPT task needs it.
Task plans must record the worker profile:
```text
Worker Profile: video-slide-production
```
## Directory Model
Use `tasks/`, not `runs/`, for local orchestration records.
```text
projects/<project-id>/
tasks/
<task-id>/
task-plan.md
task-log.md
session-01/
child-session-plan.md
child-session-handoff.md
packets/
s05-v1-slide-agent-packet.md
returns/
s05-v1-slide-agent-return.md
session-02/
child-session-plan.md
child-session-handoff.md
packets/
returns/
slides/
s05/
s05-v1-brief.md
s05-v1-prompt.md
s05-v1-image.png
s05-v1-review.md
```
Rules:
- `tasks/<task-id>/` records orchestration and agent communication.
- `slides/sNN/` remains the durable home for slide artifacts.
- Task files should not duplicate full prompts unless needed for status or debugging.
- Task records should link to slide artifacts by path.
Suggested task id pattern:
```text
YYYY-MM-DD-<short-purpose>
```
Example:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/
```
## Main Session Responsibilities
The main session is the only session that talks with the user by default.
The main session should:
- receive the user instruction;
- define the task scope and allowed running mode;
- decide the child-session split;
- create or update `task-plan.md`;
- start child sessions sequentially;
- read each `child-session-handoff.md`;
- ask the user only for real decisions, blockers, or requested sampling;
- update `task-log.md` with compact status.
The main session should not:
- write per-slide briefs by default;
- write final prompts by default;
- generate images by default;
- review every non-core image by default;
- carry all slide context in chat.
## Child Session Responsibilities
The child session is the small-batch context holder.
The child session should:
- read the project rules and the task plan;
- read the shared project context needed for the assigned slides;
- read the active `visual-system` materials needed for the assigned slides, especially:
- `visual-system/visual-system.md`;
- `visual-system/style/style-prompt-master.md`;
- `visual-system/characters/character-reference-registry.md` when a slide contains a visible character;
- write one `sNN-vN-brief.md` per assigned slide;
- create one slide-agent packet per slide;
- start exactly one slide agent per slide, sequentially;
- verify that expected files were written;
- write `child-session-handoff.md` before ending.
The child session should not:
- talk to the user unless explicitly instructed by the main session;
- process more than 3 slides by default;
- run slide agents in parallel;
- generate final prompts itself unless the slide-agent path is unavailable;
- turn task records into a full audit package.
## Slide Agent Responsibilities
The slide agent is the single-slide worker.
The slide agent should:
- read the provided packet;
- read the slide brief;
- follow the `gpt-image-2` Skill Advisor / host-native prompt workflow recorded in the packet;
- use the brief's `Reference Plan` and preserve the active visual-system reference choices in `sNN-vN-prompt.md`;
- write or update `sNN-vN-prompt.md`;
- generate the image only when the packet allows generation;
- write `sNN-vN-review.md` only when required;
- write a short return file.
The slide agent should not:
- write the brief in the default workflow;
- process a second slide;
- infer task scope beyond the packet;
- replace style-master guidance with an ad hoc style paragraph;
- replace active character image references with text-only identity description when the slide needs character continuity;
- use archived character or style references unless the packet explicitly reopens them;
- call Minimax MCP or external review tools by default.
## Slide Agent Running Modes
The main session chooses the running mode for each task.
### Mode 1: Prompt And Generate
Use when the user authorizes generation for the task scope.
Flow:
```text
child session writes brief
-> slide agent writes prompt
-> if visible character identity matters, load the required character reference image(s)
-> slide agent generates image
-> slide agent writes review if required
-> slide agent return
```
Use for:
- non-core production after task-level authorization;
- low-risk environment slides;
- continuation work where the prompt pattern is already stable.
### Mode 2: Prompt Only
Use when the user wants prompt sampling, external cross-checking, or delayed generation.
Flow:
```text
child session writes brief
-> slide agent writes prompt
-> slide agent return
```
Generation can happen later through a separate task.
Use for:
- high-risk identity slides;
- new project first-pass validation;
- prompt sampling in ChatGPT or another platform;
- any task where the user wants to inspect prompts before generation.
## Task Authorization Rule
The user gives concrete instructions to the main session for:
- agent running mode;
- slide range;
- generation permission;
- review/sampling expectations.
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 range and exceptions.
Core, repair, identity-heavy, or otherwise high-risk slides may still require prompt-only handling or an explicit pause if the task plan says so.
## Brief Structure
The brief is the universal slide execution card. It has the same structure whether or not GPT supplied a dedicated single-slide skeleton.
Recommended structure:
```text
# S-NN Slide Brief V1
## Status
## Source Basis
## slide Function
## First Read
## Risk Class
## Reference Plan
## Visual Requirements
## Character Handling
## Composition / Scale
## Light / Color / Texture
## Forbidden Drift
## Acceptance Checklist
## Prompt Handoff
```
### Brief Field Rules
`Status` records document status, task id, slide id, version, and current execution state.
`Source Basis` lists only the key sources used for this brief. Do not turn this into a full review manifest.
`slide Function` states what this slide does in the sequence.
`First Read` states what the viewer should notice first.
`Risk Class` classifies the slide, for example:
```text
environment-only
object/body detail
distant human
medium human
close/face human
core motif
repair
```
`Reference Plan` names the required style module and character references, or says `none` with a reason.
For style, the reference plan must point to the active style module in:
```text
visual-system/style/style-prompt-master.md
```
For visible character slides, the reference plan must select active character reference images from:
```text
visual-system/characters/character-reference-registry.md
```
If the slide contains a visible character and identity matters, the brief must say which reference image should be loaded for generation. Text-only character description is not enough for those slides.
`Visual Requirements` lists the positive content requirements.
`Character Handling` records visibility, identity burden, scale, posture, and prop continuity.
`Composition / Scale` records frame logic, figure size, first-read hierarchy, and placement.
`Light / Color / Texture` records the local light and material rules.
`Forbidden Drift` records the main failure modes.
`Acceptance Checklist` is the minimum local check list.
`Prompt Handoff` tells the slide agent what the prompt must carry into generation.
## Prompt Structure
The prompt file is an attachment to the brief. It should be directly runnable or easy to use for cross-platform prompt validation.
Recommended structure:
```text
# S-NN Slide Prompt V1
## Status
## Based On Brief
## Reference Inputs
## Operation Notes
## Final Prompt
## Negative / Avoid
## Output Intent
```
### Prompt Field Rules
`Status` records slide id, version, mode, and execution state.
`Based On Brief` links to the brief path.
`Reference Inputs` lists actual image references and roles.
Every prompt must preserve the visual-system usage from the brief:
- style module from `visual-system/style/style-prompt-master.md`;
- active style reference path(s), when applicable;
- active character reference path(s), when a character is visible and identity matters;
- explicit `none` with reason when no character reference should be used.
When using reference-capable host generation, use explicit visible-context roles:
```text
Image 1: identity reference
Image 2: style reference
```
`Operation Notes` records only generation-relevant steps, such as loading reference images before calling the host image tool.
For character-visible slides, `Operation Notes` must state whether image-to-image / reference-by-visible-context generation is required. If the active generation path cannot load the required character image reference, the agent must block instead of generating a text-only identity-critical image.
`Final Prompt` should be rendered through the `gpt-image-2` Skill Advisor workflow and should be copyable into another image-generation platform with minimal cleanup.
`Negative / Avoid` should be copyable as a negative prompt or avoid list.
`Output Intent` records the intended project output path and cross-validation note if relevant.
Do not put these in normal prompt files unless needed for the run:
- full project explanation;
- long source-file audit;
- detailed Skill file narrative;
- review conclusions;
- task orchestration history.
## Review Structure
Reviews are optional by default.
Create `sNN-vN-review.md` only when:
- the slide is a core trial slide;
- the slide is identity-heavy;
- the slide is a repair target;
- the user explicitly requests a review record;
- the agent detects likely failure or uncertainty;
- the image is being accepted as a durable reference.
Recommended structure:
```text
# S-NN Slide Review V1
## Status
## Generation Trace
## Local File Check
## Local Visual Check
## Acceptance Checklist
## Issues
## Decision / Next Action
```
Default review rule:
- Use local capabilities only.
- Do not call Minimax MCP by default.
- Do not transmit private project images to external services unless the user explicitly authorizes it for that task.
- For character-visible slides, check whether the required visual-system character reference was actually loaded or whether the run was only text-guided.
- For style-sensitive slides, check whether the prompt used the active style module rather than a one-off style paragraph.
Non-core generated slides may instead be recorded in:
```text
tasks/<task-id>/task-log.md
slides/slides.md
```
## Task File Structures
### `task-plan.md`
```text
# <Task Title>
## Status
## User Instruction
## Worker Profile
## Running Mode
## slide Scope
## Child Session Split
## Shared Context
## Rules
## Visual-System Usage
## Expected Outputs
## User Review / Sampling Plan
## Stop Conditions
```
### `child-session-plan.md`
```text
# Child Session NN Plan
## Status
## Parent Task
## Assigned slides
## Shared Context To Read
## Visual-System Files To Read
## Per-slide Work Order
## Agent Packet Paths
## Stop Conditions
```
### `slide-agent-packet.md`
```text
# S-NN Slide Agent Packet V1
## Status
## Target slide
## Allowed Actions
## Input Files
## Output Files
## Reference Roles
## Visual-System Requirements
## Gpt-Image-2 Advisor Rule
## Generation Rule
## Review Rule
## Return File
```
### `slide-agent-return.md`
```text
# S-NN Slide Agent Return V1
## Status
## Files Written
## Generation Result
## Review Result
## Blockers
## Next Action
```
### `child-session-handoff.md`
```text
# Child Session NN Handoff
## Status
## Completed slides
## Files Written
## Problems / Repairs Needed
## User Decisions Needed
## Next Session Input
```
### `task-log.md`
Keep this compact. It is not a full audit.
```text
# Task Log
## Status
## Timeline
## Child Session Results
## slide Status Summary
## Open Decisions
```
## Planned File And Folder Changes
This plan should be implemented after user review.
### Add Docs
```text
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-brief-structure.md
docs/workflows/slide-prompt-structure.md
docs/workflows/slide-review-structure.md
docs/workflows/slide-agent-packet.md
```
Possible consolidation:
- If this is too many files, keep one stable workflow document and one templates document.
### Add Templates
```text
docs/templates/task-plan-template.md
docs/templates/child-session-plan-template.md
docs/templates/child-session-handoff-template.md
docs/templates/slide-agent-packet-template.md
docs/templates/slide-agent-return-template.md
docs/templates/slide-brief-template.md
docs/templates/slide-prompt-template.md
docs/templates/slide-review-template.md
```
### Update Workspace Rules
```text
VIDEO_WORKBENCH.md
AGENTS.md
```
Expected updates:
- add `tasks/` as the local task orchestration directory;
- define main session / child session / slide agent boundaries;
- define the two slide-agent running modes;
- state that task-level user instruction controls generation authorization;
- state that child sessions and slide agents must use active `visual-system` materials;
- state that visible character identity requires actual character image references, not text-only prompting;
- state that slide prompts must use the `gpt-image-2` Skill Advisor workflow;
- state that review defaults to local-only and does not call Minimax MCP.
### Add Project Task Directory During First Trial
For the `在路上` character-consistency trial:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/
```
Expected substructure:
```text
task-plan.md
task-log.md
session-01/
session-02/
```
### Existing Slide Artifact Changes During First Trial
Likely generated or updated:
```text
projects/2026-06-23-在路上/slides/s05/s05-v1-brief.md
projects/2026-06-23-在路上/slides/s05/s05-v1-prompt.md
projects/2026-06-23-在路上/slides/s21/s21-v1-brief.md
projects/2026-06-23-在路上/slides/s21/s21-v1-prompt.md
projects/2026-06-23-在路上/slides/s14/s14-v1-brief.md
projects/2026-06-23-在路上/slides/s14/s14-v1-prompt.md
projects/2026-06-23-在路上/slides/s25/s25-v1-brief.md
projects/2026-06-23-在路上/slides/s25/s25-v1-prompt.md
projects/2026-06-23-在路上/slides/s33/s33-v1-brief.md
projects/2026-06-23-在路上/slides/s33/s33-v1-prompt.md
```
Image and review files depend on task running mode.
## First Trial Recommendation
Use the character-consistency slides as the first orchestration trial.
Task:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/
```
Child session split:
```text
session-01: s05 -> s21 -> s14
session-02: s25 -> s33
```
Recommended first running mode:
```text
prompt only
```
Reason:
- This validates the new brief and prompt structure without spending image-generation context.
- The user can sample prompts externally if desired.
- A later task can use the same prompts for generation.
If the user chooses `prompt and generate`, the task plan must record that instruction and the exact slide scope.
## Open Implementation Decisions
1. Whether to split the stable docs into five files or keep a single workflow document plus templates.
2. Whether to update `AGENTS.md` immediately or only update `VIDEO_WORKBENCH.md` for this local workflow.
3. Whether the first trial should be `prompt only` or `prompt and generate`.
4. Whether old broad-run candidate images for `s05`, `s14`, `s21`, `s25`, and `s33` should be marked as comparison-only before the character-consistency task starts.

View File

@ -0,0 +1,522 @@
# Slide Task Orchestration
## Status
- Status: active workflow rule.
- 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 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
- Keep the main session small enough to survive long production work.
- Keep style and character continuity anchored in `visual-system/`.
- Keep user review focused on real decisions, not every generated image.
- Keep task evidence light but sufficient for continuation after context compression.
- Keep mandatory write guards inside child sessions, so the main orchestration session can stay lightweight in production.
- Separate test / audit work from normal production so routine production does not pay test-level token cost.
## Worker Profiles
Current profile:
```text
video-slide-production
```
This profile uses:
- `visual-system/` as the production authority;
- `visual-system/style/style-prompt-master.md` for style modules and style prompt language;
- `visual-system/characters/character-reference-registry.md` for active character references;
- `slides/` for slide artifacts;
- `gpt-image-2` Skill Advisor / host-native prompt workflow.
For Video Workbench, the `gpt-image-2` Skill is used as the prompt/spec Advisor. Normal project-bound image generation does not need to prove Garden, API, multipart upload, or local `gpt-image-2` script execution. The expected generation path is:
```text
gpt-image-2 Advisor prompt/spec
-> load the real reference image into visible conversation context when references are required
-> call host built-in image generation with the loaded image named as Image 1 / Image 2
-> copy the host output into slides/sNN/
-> record prompt/spec evidence, loaded-reference evidence, host output path, and compact handoff/status
```
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/<project>/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/<project>/remotion/ # source
projects/<project>/renders/ # rendered MP4s or still checks unless overridden
projects/<project>/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
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 the active profile, for example:
```text
Worker Profile: video-slide-production
```
or:
```text
Worker Profile: remotion-video-production
```
## Operating Lines
Use two lines:
```text
test/audit
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 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` 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:
```text
review: none
```
Generated images are recorded as production-pass outputs. They do not need per-image user review before the workflow continues. If the user later finds a result unusable, run an append-only repair or retry as a new version.
Project phase is recorded in `projects/<project>/project.md`. New projects default to `test/audit`. Once the user explicitly authorizes formal production, switch the project phase to `production-light`; future runs then load the production-light workflow by default. A named session or slide scope can still override back to `test/audit` for local diagnosis.
## Directory Model
Use project-local `tasks/` for orchestration records:
```text
projects/<project-id>/
tasks/
<task-id>/
task-plan.md
task-log.md
production-run-status.md # for multi-package production or compression-safe continuation
session-01/
child-session-handoff.md
# production-light default: no packets/returns
# test/audit or exception scopes may add:
packets/
s05-v1-slide-agent-packet.md
returns/
s05-v1-slide-agent-return.md
slides/
s05/
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:
- `tasks/<task-id>/` 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.
- `production-run-status.md` is the compact continuation surface for multi-package production. It records scope, completed units, active child session, next cursor, latest callback, and stop conditions.
- Task records do not own the slide version number. Before each slide run, resolve the next unused `sNN-vN-*` version from the existing files in `slides/sNN/`, then write only that new version.
- Existing slide artifacts are historical evidence even when incomplete or superseded. Do not overwrite them to make a later task look cleaner.
- Suggested task id pattern: `YYYY-MM-DD-<short-purpose>`.
## Artifact Version And Write Policy
Default policy:
- New task execution appends a new slide version. It does not reuse or overwrite an existing `vN`.
- The next version is the next unused integer after all existing files matching `sNN-v*-*` in the slide folder, regardless of whether earlier versions have missing brief, prompt, image, or review files.
- Incomplete earlier versions should be recorded as incomplete, broad-run, interrupted, superseded, or invalid as appropriate. Do not backfill a missing prompt or brief in a way that implies it was the original generation prompt.
- Every child session or slide-agent packet must state `Overwrite allowed: no` unless the user explicitly authorizes an overwrite repair for named files.
- Before writing brief, prompt, image, review, packet, return, or handoff files, the writing agent must check whether each target file already exists. If a target exists and overwrite is not explicitly authorized, the agent must stop and report an artifact collision instead of writing.
- An approved overwrite repair must preserve or explicitly cite the prior file state before replacement. Routine production and workflow tests should not use overwrite repair.
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/<project>/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
The main session is the only session that talks with the user by default.
Responsibilities:
- receive the user instruction;
- define the worker profile, running mode, slide scope, and review expectations;
- read the project phase from `project.md`, unless the user explicitly overrides it for a named session/scope;
- create or update `task-plan.md` only with the active scope and dispatch/callback status needed for continuation;
- split work into sequential child sessions;
- start child sessions one at a time and name them with a user-facing `子会话:...` title when the tool surface supports thread naming;
- record the parent callback target for the child session;
- read the child session's short completion handoff after callback;
- ask the user only for blockers, core decisions, or requested sampling;
- update `task-log.md` with compact status.
- update `production-run-status.md` after each callback when the task may continue across multiple child sessions.
The main session should not write per-slide briefs, final prompts, images, or routine reviews by default. In production-light it should also not redo routine child-session checks unless the child session reports a problem.
Production orchestration default:
- Launch or continue exactly one child session for the approved scope.
- Record the parent thread id and require callback-only completion unless the task plan explicitly declares polling fallback.
- After dispatch, stop routine waiting. Do not inspect the child thread for routine completion.
- In `production-light`, instruct the child session to work directly. Do not start Agent/SubAgent workers, do not write packet files, do not write return receipt files, and do not run a final verification pass.
- The child session must write `child-session-handoff.md` before sending any callback.
- The child session must complete all allowed production-light writes, `slides/slides.md` updates, compact handoff writing, and any narrow file-existence checks before callback.
- The child session sends a concise callback to the parent only as its final action. After a successful callback, it must not write or verify additional project files.
- The callback payload must include status, topology, resolved versions, handoff path, image paths if complete, and any problems or user decisions needed.
- If a package would exceed 8 ordinary production slides, split it into smaller packages unless the task plan explicitly defines a custom package size.
- Consume only the handoff's status, topology, review mode, resolved versions, image paths, and needs-user field by default.
- Continue to the next approved slide/scope when status is `complete` and the handoff reports no problems.
- For unattended production, reload the minimal project/task state after callback and continue dispatching packages until the target scope is complete or a stop condition is present.
- Open detailed prompt, return, ledger, or image evidence only when the handoff reports `blocked`, `failed`, `warning`, artifact collision, duplicate worker, user-requested audit, or explicit sampling/review.
Polling fallback is allowed only when callback tooling is unavailable or the user explicitly requests polling for a named run. If fallback polling is used, the task plan must record the reason, the status-check schedule, and the timeout / blocker policy before dispatch.
### Child Session
The child session is the small-batch context holder.
Default capacity:
- maximum 8 ordinary production slides per child session;
- fewer slides for identity-heavy, repair-heavy, core-risk, or context-expensive work;
- sequential only, not parallel.
This maximum is a default child-session chunk size, not a project-wide production cap. After the workflow is proven stable, the main session may dispatch additional child sessions or a broader user-approved scope while preserving the per-child-session capacity rule unless the task plan explicitly changes it.
The 8-slide default is based on accepted production-light compression validation in `projects/2026-06-23-在路上/tasks/2026-06-25-8slide-compression-validation/`: eight images accepted into the production pass by user rule, 174K tokens, 67% context, and 38m37s elapsed. The callback-final contract was verified in the child thread tail. The earlier 5-slide validation remains historical capacity evidence and exposed the callback-order defect, so child prompts must still state that callback is the final action.
Responsibilities:
- read project rules and the task plan;
- read shared project context for assigned slides;
- 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/<project>/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;
- in `test/audit`, repair, or exception scopes, verify expected files and run the required completion gate before returning;
- run instruction review only when the task plan or packet requires review; production-light defaults to no review;
- 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
The slide agent is the optional single-slide worker for `test/audit`, repair, exception handling, explicit review, or intentionally isolated slide work. It is not the default production-light carrier.
Default capacity:
- one slide per invocation;
- no ranges;
- no batches.
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.
Lifecycle rule:
- A slide agent is one-shot.
- It receives exactly one immutable packet.
- It owns exactly one slide/version.
- It writes exactly one compact return.
- After the return is recorded, the agent is terminal / closed.
- Closed agents must not be continued, reused, or assigned follow-up work.
- Any repair, retry, or next slide must launch a new agent with a new packet and, when writing slide artifacts, a new append-only version.
The slide agent must not:
- overwrite existing slide artifacts unless the packet explicitly authorizes overwrite repair for named files;
- write the brief in the default workflow;
- process a second slide;
- 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
### Prompt And Generate
Use when the user authorizes generation for the task scope.
Flow:
```text
child session writes brief
-> child session writes prompt
-> if visible character identity matters, load required character reference image(s)
-> child session calls host image generation through the visible-context reference path
-> child session updates slides/slides.md
-> child session writes compact handoff and callbacks parent
```
For this workflow, "load required character reference image(s)" means the actual local image is made visible to the generation context before host image generation. A local filesystem path written in a prompt is traceability only and does not count as loading the image.
When a slide agent is used, it must not treat "Garden/API not used" as a failure. The expected evidence is that the Advisor prompt/spec was prepared and the host image-generation path was used with the required visible-context reference.
### Prompt Only
Use when the user wants prompt sampling, external cross-checking, or delayed generation.
Flow:
```text
child session writes brief
-> child session writes prompt
-> child session writes compact handoff and callbacks parent
```
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/<project>/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/<project>/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:
- running mode;
- slide scope;
- generation permission;
- Remotion implementation or render permission;
- operating line;
- review or sampling expectations.
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.
For every slide:
- use active visual-system files, not memory reconstruction;
- choose style from `visual-system/style/style-prompt-master.md`;
- 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;
- the brief must name the character reference image(s);
- the prompt must assign visible-context roles such as `Image 1: identity reference`;
- if the active generation path cannot load the required character image reference, the agent must block instead of generating a text-only identity-critical image.
## Document Structures
Stable templates live in:
```text
docs/workflows/slide-task-templates.md
```
Required per-slide artifacts:
```text
sNN-vN-design.md # required for cover/PPT/science-video/title/post-production-heavy slides
sNN-vN-design-en.md # optional English companion; default design remains Chinese
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
```
`design` is the human-facing page or cover design spec. It is for user review and later layout / typography / post-production. It may include visual concept, intended text, text placement, font/color guidance, case references, design constraints, and post-production notes. It is not the prompt and should not be treated as a runnable image-generation artifact.
`sNN-vN-design.md` is Chinese by default. Use `sNN-vN-design-en.md` only as an optional English companion when needed.
`brief` is the universal execution card. It is written by the child session.
`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.
Write `design` before `brief` for cover pages, PPT pages, science-video pages, title cards, explainers, or any slide that needs human text/layout/post-production decisions. Pause for user confirmation after `design` unless the task explicitly authorizes continuing through `brief`, `prompt`, and generation. Ordinary MV shot slides can skip `design` and continue directly through `brief -> prompt -> image`.
## Production-Light Closeout
Production-light uses a minimal closeout, not a full audit gate.
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. 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.
## Test / Audit Completion Gate
Use the fuller completion gate only in `test/audit`, repair, explicit review, or exception scopes. The child session should confirm:
- 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
Production-light default review is `none`. Test/audit default review is local-only.
- Do not call Minimax MCP by default.
- Do not transmit private project images to external services unless the user explicitly authorizes it for that task.
- Completeness checking is a test/audit concern. Production-light uses only minimal closeout.
- Instruction / visual review is optional and depends on the task plan.
- If review mode is `none`, do not write `sNN-vN-review.md`; the handoff, and the return when a slide Agent was used, must still state that review was intentionally suppressed.
- For character-visible slides, the prompt or handoff should state the required character image reference role.
- For style-sensitive slides, the prompt should use the active style module from the style master.
- For host-native generation, production-light records only what is useful for continuation:
- `gpt-image-2` Advisor prompt/spec evidence;
- loaded visible-context image role such as `Image 1`;
- copied project image path.
Routine non-core generated slides can be tracked in:
```text
tasks/<task-id>/task-log.md
slides/slides.md
```

View File

@ -0,0 +1,523 @@
# Slide Task Templates
## Status
- Status: active template reference.
- Companion workflow: `docs/workflows/slide-task-orchestration.md`.
Copy these structures into project-local task and slide files as needed. Keep them compact; do not turn production work into audit reports.
Use two lines:
- `production-light`: normal production after the project look has been proven. Default review mode is `none`.
- `test/audit`: core-shot proving, workflow debugging, failure investigation, or explicit user-requested review. Richer records are allowed.
## Task Plan
Production-light form:
```text
# <Task Title>
## Active Scope
- Line: production-light
- Worker profile:
- Running mode:
- Review mode: none
- Slides:
- Remotion source root: `projects/<project>/remotion/` if applicable
- Remotion render target: <composition / output path / not applicable>
- Child session:
- Callback target:
- Write policy: append-only; overwrite allowed: no
- Status:
## Context To Use
## Stop Conditions
```
Use a longer plan only in `test/audit`.
```text
# <Task Title>
## Status
- Task id:
- Worker profile:
- Running mode:
- Status:
## User Instruction
## Slide Scope
## Child Session Split
## Shared Context
## Visual-System Usage
## Remotion Usage
## Generation Evidence Policy
## Rules
## Expected Outputs
## User Review / Sampling Plan
## Stop Conditions
```
## Task Log
Production-light form:
```text
# Task Log
## Status
## Dispatch / Callback Receipts
- YYYY-MM-DD HH:MM dispatch: <session>, <scope>, <line>, <review mode>, <callback target>
- YYYY-MM-DD HH:MM callback: <status>, <topology>, <versions>, <handoff path>, <image paths>, <needs_user>
## Slide Status Summary
## Open Decisions
```
## Production Run Status
Use this for any production request that may continue across multiple child sessions or survive parent-session compression. Keep it current and compact.
```text
# Production Run Status
## Status
- Project:
- Lifecycle phase:
- Line:
- Worker profile:
- Running mode:
- Review mode:
- Package size:
- User confirmation:
- Current status:
## Scope
- Total target units:
- Completed units:
- Active child session:
- Next cursor:
- Remotion source root:
- Remotion composition ID:
- Remotion render output:
## Callback Target
- Parent thread:
- Callback mode:
## Latest Callback
- Status:
- Topology:
- Resolved versions:
- Handoff path:
- Image paths:
- Remotion output:
- Problems:
- Needs user:
## Stop Conditions
```
Field rules:
- `Package size` records the default or the task-specific validation override.
- `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.
## Child Session Plan
Use this only when the child needs its own local plan. Normal production-light packages can proceed from the parent dispatch plus the compact handoff.
Production-light form:
```text
# Child Session NN Plan
- Line: production-light
- Parent task:
- Parent callback target:
- Assigned slides:
- Running mode:
- Review mode: none
- Remotion source root:
- Remotion checks:
- Write policy: append-only; overwrite allowed: no
- Shared context:
- Visual-system files:
- Topology: direct-child; no Agent/SubAgent unless explicitly requested
- Stop conditions:
- Callback final action: after the child sends a successful callback, it must not write or verify additional project files.
```
## Child Session Handoff
Production-light form:
```text
# Child Session NN Handoff
- Status:
- Topology: direct-child | test/audit-with-agent | repair
- Callback: ready-to-send-as-final-action | blocked | not required
- 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:
- Parent summary:
```
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`, `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.
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 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.
## Slide Agent Packet
Use this only in `test/audit`, explicit review, repair, exception handling, or a deliberately isolated single-slide run. Production-light defaults to the child session writing the brief, prompt, image, `slides.md` update, and handoff directly.
```text
# S-NN Slide Agent Packet V1
## Status
## Target Slide
## Allowed Actions
## Input Files
## Output Files
## Artifact Version / Write Policy
## Reference Roles
## Visual-System Requirements
## Gpt-Image-2 Advisor Rule
## Remotion Skill Rule
## Host Generation Evidence Rule
## Generation Rule
## Review Rule
## Completion Gate Rule
## Lifecycle Rule
## 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.
Test/audit or exception form:
```text
# S-NN Slide Agent Return V1
- Status:
- Slide/version:
- Prompt:
- Image:
- Review mode: none
- Completeness gate:
- Advisor / host-native:
- Reference roles loaded:
- Agent lifecycle: terminal
- Blockers:
- Parent summary:
```
Return field rules:
- `Completeness gate` records only the required receipt facts: expected files exist, append-only version, no-overwrite status, reference loading status, and review absence/presence according to packet.
- `Agent lifecycle` states that this worker is terminal / closed after this return.
- `Parent summary` should be short and suitable for copying into the child-session handoff.
- A return with `blocked`, `failed`, or `warning` must name the exact artifact or condition that the child/main session should inspect.
- Do not add a narrative review, full file inventory, or long source audit to the return. Production-light direct-child packages should not write this return at all.
## Slide Design
Use this 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. Ordinary MV shot slides may skip this and start at `Slide Brief`. The default `sNN-vN-design.md` is written in Chinese. If an English companion is needed, add `sNN-vN-design-en.md` beside it.
```text
# S-NN Slide Design V1
## Status
## Design Purpose
## Discussion Summary
## Visual Concept
## Image Base Requirements
## Text / Typography Plan
## Layout / Safe Areas
## Color Guidance
## Post-Production Notes
## Constraints / Avoid
## Confirmation Gate
```
Design field rules:
- Write the default `sNN-vN-design.md` in Chinese unless the user explicitly asks otherwise.
- Use `sNN-vN-design-en.md` only as an optional English companion or translation; it must not replace the Chinese default.
- `Design Purpose` says who the design is for and why a separate design file is needed.
- `Discussion Summary` captures the user-approved design direction and tradeoffs.
- `Image Base Requirements` describes what the generated image should and should not contain; if text will be added later, explicitly say the generated image must contain no text.
- `Text / Typography Plan`, `Layout / Safe Areas`, and `Color Guidance` are for human post-production, not for image generation unless the task explicitly asks to render text into the image.
- `Confirmation Gate` states what must be confirmed before `brief`, `prompt`, or image generation starts.
## Slide Brief
```text
# S-NN Slide Brief V1
## Status
## Source Basis
## Slide Function
## First Read
## Risk Class
## Reference Plan
## Visual Requirements
## Character Handling
## Composition / Scale
## Light / Color / Texture
## Forbidden Drift
## Acceptance Checklist
## Prompt Handoff
```
Brief field rules:
- `Source Basis` lists only key sources.
- `Risk Class` uses values such as `environment-only`, `object/body detail`, `distant human`, `medium human`, `close/face human`, `core motif`, or `repair`.
- `Reference Plan` must name the active style module and any active character references.
- Visible character slides must select character reference images from `visual-system/characters/character-reference-registry.md`.
- `Prompt Handoff` tells the child session, or the slide agent when one is used, what must be carried into the prompt.
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/<project>/remotion/`.
## Slide Prompt
```text
# S-NN Slide Prompt V1
## Status
## Based On Brief
## Reference Inputs
## Operation Notes
## Advisor / Host-Native Record
## Final Prompt
## Negative / Avoid
## Output Intent
```
Prompt field rules:
- `Based On Brief` links to `sNN-vN-brief.md`.
- `Reference Inputs` lists actual image references and roles.
- `Operation Notes` records only generation-relevant steps.
- `Advisor / Host-Native Record` records the `gpt-image-2` mode result, the Skill/template files used for prompt/spec construction, and that Garden/API execution is not expected by default.
- `Final Prompt` should be copyable into another image-generation platform with minimal cleanup.
- 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/<project>/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.
- Resolve the version by scanning existing `slides/sNN/sNN-v*-*` files and choosing the next unused integer.
- 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/<project>/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
Use this only in `test/audit` or explicit review tasks. Production-light default is no review file.
```text
# S-NN Slide Review V1
## Status
## Generation Trace
## Host Generation Evidence
## Local File Check
## Local Visual Check
## Acceptance Checklist
## Issues
## Decision / Next Action
```
Review field rules:
- Use local capabilities by default.
- Do not call Minimax MCP unless the user explicitly authorizes it for the task.
- For character-visible slides, record whether the required character reference image was loaded.
- For style-sensitive slides, record whether the active style module was used.
- `Host Generation Evidence` should record `Garden/API expected: no` unless the task explicitly changes policy, the visible-context image roles actually loaded, the host generated-image source path, the copied project image path, and any hash/file verification performed.

View File

@ -0,0 +1,198 @@
# R4 Formal-Run Simulation Handoff
Date: 2026-06-24
Project:
```text
projects/2026-06-23-在路上
```
## Status
The third session / SubAgent workflow test is complete.
R3 accepted results:
- `S-33` -> `slides/s33/s33-v2-image.png`
- `S-06` -> `slides/s06/s06-v2-image.png`
R3 mechanism result:
- Clean child session: `019ef876-c5b2-7202-b204-774cb5fb95fd`
- `Agent S-33`: `019ef87a-3aa1-75a2-a97c-de8f57e234e1`
- `Agent S-06`: `019ef886-8797-7243-9427-d45065fcfc47`
- Both slide agents were distinct one-shot internal workers.
- Review files were intentionally absent.
- Prompts recorded `gpt-image-2` Advisor mode plus style and character references.
- User accepted both images.
The user will manually commit the current documentation updates. R4 should start in a new clean session after that commit.
## Rules Updated Before R4
Read these first in the new session:
```text
AGENTS.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
```
Key runtime rules:
- `子会话` / `session`: clean user-visible Codex child thread, created with `create_thread`; do not use forked inherited-context threads by default.
- `Agent` / `SubAgent`: internal one-shot worker owned by the child session.
- One slide Agent handles exactly one slide/version, writes one return, then becomes terminal / closed.
- Closed Agents must not be continued or reused.
- Main session production default: dispatch, wait, read short handoff, continue. Do not audit prompt / return / ledger / image details when the child reports complete with completion gate pass.
- Waiting rule: first wait 10 minutes; if incomplete, poll every 1 minute; stop routine waiting at 15 minutes total and inspect/report timeout.
- Child-session completion gate is mandatory.
- Instruction / visual review is optional and should run only when the task asks for review.
- `无 review` means no `sNN-vN-review.md`; return and handoff still record that review was intentionally suppressed.
## Completion Gate Expected From Child Session
The child session must verify and summarize:
- each target slide version was resolved by scanning existing `slides/sNN/sNN-v*-*` files;
- no target file was overwritten;
- expected brief, packet, prompt, image, and return files exist for each slide;
- review files are present or absent according to the task rule;
- each slide/version has exactly one owning Agent;
- each Agent is terminal / closed after return;
- visible-context image references were loaded when required, or generation blocked before text-only identity-critical output;
- generated project image paths and hashes are recorded when available;
- handoff includes a compact parent summary.
If any item fails, return `blocked`, `failed`, or `warning` and name what the main session should inspect.
## Slide Inventory
### Project-Confirmed Complete / Keep
Total: 11.
| Group | Shots | Notes |
| --- | --- | --- |
| Core / anchor trial | `S-01`, `S-10`, `S-46`, `S-47`, `S-51` | Accepted five-shot visual trial. `阶段五-核心单镜.md` only expands `S-10`, `S-46`, and `S-51`; `S-01` and `S-47` were included by the anchor-test package. |
| Character-consistency intake | `S-05`, `S-14`, `S-21`, `S-25`, `S-33` | These are the five shots from `阶段五-人物一致性单镜.md`. `S-05` has an overwrite workflow defect but has prompt/review/reference evidence. `S-14` image is accepted but has historical duplicate-Agent mechanism defect. `S-21`, `S-25`, and `S-33` are accepted. |
| Temporary no-single-shot-skeleton test | `S-06` | Accepted in R3 as `s06-v2`; clean `session-04` continuation and mechanism pass. |
### Generated Before But Must Be Redone
These have broad-run `v1` images but no reliable brief/prompt/review trace. They cannot prove use of the style master or active references. Keep the existing `v1` files as historical evidence only; formal production should create the next append-only version.
```text
S-02, S-03, S-04, S-07, S-08, S-09,
S-11, S-12, S-13, S-15, S-16, S-17,
S-18, S-19, S-20, S-22, S-23, S-24,
S-26, S-27, S-28, S-29, S-30, S-31,
S-32, S-34
```
Total: 26.
### Not Started
These have no slide artifacts yet.
```text
S-35, S-36, S-37, S-38, S-39, S-40,
S-41, S-42, S-43, S-44, S-45,
S-48, S-49, S-50
```
Total: 14.
## Recommended R4 Scope
Use:
```text
S-02
S-03
S-04
```
Expected new versions:
```text
s02-v2
s03-v2
s04-v2
```
Reasoning:
- They are the first unfinished consecutive shots after accepted `S-01`.
- They start real production from the beginning rather than only testing isolated character shots.
- They exercise three useful cases in one child session:
- `S-02`: distant small traveler / environment-led human shot.
- `S-03`: body / prop detail shot.
- `S-04`: landscape-led no-face road shot.
- All three already have broad-run `v1` images, so append-only version handling is tested.
Recommended task settings unless user changes them:
```text
running mode: prompt and generate
review: none
completion gate: required
main-session audit: none unless child handoff reports warning / blocked / failed
child-session capacity: 3 slides
```
## R4 Test Goals
R4 should simulate formal production rather than another audit-heavy mechanism test.
Main-session expectations:
- create one clean child session;
- send the R4 packet for `S-02`, `S-03`, and `S-04`;
- wait 10 minutes before checking;
- if incomplete, poll every 1 minute up to 15 minutes total;
- when the child reports `complete` with `completion_gate: pass`, continue without opening detailed prompt / return / ledger / image files;
- only inspect details if the child returns `blocked`, `failed`, `warning`, missing completion evidence, duplicate worker, artifact collision, or user-requested audit.
Child-session expectations:
- handle all 3 assigned slides sequentially;
- resolve versions by scanning existing files;
- write one brief and one packet per slide;
- launch exactly one internal one-shot Agent per slide;
- ensure each Agent closes after return;
- write prompt and image for each slide;
- write no review files unless the task explicitly changes review mode;
- run the completion gate;
- return a compact handoff usable by the main session.
## After R4
If R4 succeeds, production does not need to remain limited to only three total shots. The next step can either:
- continue in additional 3-shot child sessions, or
- move to a broader user-approved production scope while preserving child-session completion gates and one-shot slide Agents.
The next natural unfinished sequence after R4 would be:
```text
S-07
S-08
S-09
```
because `S-05` and `S-06` are already in the keep set.
## Non-Goals For R4
- Do not invoke CCPE.
- Do not ask GPT V2 for final prompts.
- Do not call Minimax MCP or external vision/review tools unless the user explicitly changes the task.
- Do not reuse or continue R3 `Agent S-33` or `Agent S-06`.
- Do not backfill old broad-run `v1` images as if they had original prompt traces.
- Do not overwrite existing slide artifacts.

View File

@ -0,0 +1,244 @@
# R5 Brief-Ownership Formal-Run Handoff
Date: 2026-06-24
Project:
```text
projects/2026-06-23-在路上
```
## Status
R4 visual production is complete, but the R4 mechanism test should be treated as failed for the next planning step.
R4 accepted images:
- `slides/s02/s02-v2-image.png`
- `slides/s03/s03-v2-image.png`
- `slides/s04/s04-v2-image.png`
User accepted all three images. Image quality is no longer the main concern.
R4 mechanism result:
- Clean child session: `019ef8cf-4ab1-7b41-877b-979dc25b0a76`
- `Agent S-02`: `019ef8d1-188a-70c3-8a7c-4e915144a276`
- `Agent S-03`: `019ef8e2-5229-72a3-93c9-16e46a87d3bf`
- `Agent S-04`: `019ef8ec-8032-7de0-a8b8-0d40d456fbaa`
- `S-02` took about `13m55s`; user observed child-session context at about `107K` tokens after this first package.
- User observed total child-session context around `132K` tokens after the second package.
R4 failed the intended mechanism check because brief ownership was wrong:
- `s02-v2-brief.md`, `s03-v2-brief.md`, and `s04-v2-brief.md` were generated by the slide Agents.
- They were not generated and confirmed by the visible child session before launching each slide Agent.
- Evidence: each slide Agent return lists the brief and packet under worker-written files.
- `S-04` also has a sequencing warning: the worker launched before visible-child brief/packet prewrite confirmation.
No overwrite, duplicate worker, extra slide, or review-file defect was observed in R4.
## Read First In R5
Read these before starting work:
```text
AGENTS.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
```
Use this handoff as the R5 task entrypoint.
## R5 Goal
R5 should answer two questions:
1. Can the visible child session generate slide briefs and packets before launching each one-shot slide Agent?
2. How many real slide shots can one clean visible child session carry before context pressure makes the workflow unreliable?
R5 is not primarily an image-quality test. Images still need to be generated and user-accepted, but the key test is whether the workflow boundary is correct.
## R5 Hard Rule: Brief Ownership
The visible child session must own brief generation.
For each slide/version:
1. The visible child session scans the slide folder and resolves the next unused version.
2. The visible child session writes `sNN-vN-brief.md`.
3. The visible child session writes `sNN-vN-packet.md`.
4. The visible child session confirms both files exist and target paths do not collide.
5. Only then may it launch the one-shot slide Agent.
6. The slide Agent reads the brief and packet, then writes prompt/image/return.
7. The slide Agent must not create or rewrite the brief or packet.
If the worker writes, rewrites, or claims to have written `sNN-vN-brief.md` or `sNN-vN-packet.md`, R5 should return `warning` or `failed` even if the image is acceptable.
## R5 Completion Gate Additions
In addition to the existing completion gate, the child session must verify:
- brief and packet were created by the visible child session before worker launch;
- worker return does not list brief or packet under worker-written files;
- worker packet/return timestamps are after visible-child brief/packet timestamps;
- exactly one owning worker exists per slide/version;
- no review files exist when review is disabled;
- generated image path and hash are recorded;
- child context usage is reported if visible in the runtime, or left for user observation if not available to the child.
If any item fails, report `warning`, `failed`, or `blocked`; do not compress it into a pass.
## Recommended R5 Scope
Use the next natural unfinished sequence after accepted `S-05` and `S-06`:
```text
S-07
S-08
S-09
```
Expected new versions if no new files appear before R5:
```text
s07-v2
s08-v2
s09-v2
```
Reasoning:
- `S-02`, `S-03`, and `S-04` are visually accepted.
- `S-05` and `S-06` are already in the keep set.
- `S-07`, `S-08`, and `S-09` continue the early sequence and cover useful variation:
- `S-07`: environment pressure against tiny traveler.
- `S-08`: body/boot/mud detail.
- `S-09`: large bridge/shadow pressure begins.
## Recommended R5 Package Split
Use one clean visible child session.
Package 1:
```text
S-07
```
Wait by workflow:
- first check after 10 minutes;
- if incomplete, poll every 1 minute;
- at 15 minutes total, inspect status or report timeout/blocker.
After Package 1, parent should check only the compact handoff. The user checks image acceptance.
Package 2, only if Package 1 does not fail the brief-ownership rule:
```text
S-08
S-09
```
Process sequentially inside the same child session. Apply the same per-slide wait discipline and record context growth.
If Package 1 fails brief ownership, stop R5 and repair the workflow contract before generating more images.
## Recommended Task Settings
```text
running mode: prompt and generate
review: none
completion gate: required
main-session audit: none unless child handoff reports warning / blocked / failed
child-session capacity target: measure 1 shot, then 2 more shots in the same child session
overwrite allowed: no
```
## Required Production Route
For every image-generation prompt:
- Use the `gpt-image-2` Skill Advisor / host-native workflow.
- Run the Skill mode check:
```powershell
node C:\Users\wangq\.agents\skills\gpt-image-2\scripts\check-mode.js --json
```
- Read the relevant `gpt-image-2` Skill template/reference file before drafting the prompt.
- Record the Skill mode, template/reference path, and source files actually read.
- Use `visual-system/style/style-prompt-master.md`.
- Use `visual-system/characters/character-reference-registry.md` and active character image references when visible identity/body continuity matters.
- Visible character identity must not be generated from text-only prompts.
## Main-Session Expectations
The main session should:
- create exactly one clean visible child session for R5;
- send Package 1 only;
- wait by workflow and read only the compact handoff unless warning/blocked/failed appears;
- ask the user to inspect the image;
- continue the same child session with Package 2 only after Package 1 passes the brief-ownership gate and the image is accepted;
- record observed context usage after each package if the user reports it;
- avoid opening prompt/image/return details unless the child reports a problem or the user requests inspection.
## Child-Session Expectations
The child session should:
- write visible-child-owned brief and packet before launching each worker;
- launch one internal one-shot worker per slide/version;
- keep each worker terminal/closed after return;
- prevent worker-generated brief/packet;
- write no review files;
- perform the expanded completion gate;
- return compact handoffs.
The compact handoff must explicitly include:
- status;
- completion gate result;
- brief owner result for each slide;
- worker ids;
- artifact paths;
- image hashes;
- review mode/result;
- context usage if available;
- whether parent should inspect anything.
## Non-Goals For R5
- Do not invoke CCPE.
- Do not ask GPT V2 for final prompts.
- Do not call Minimax MCP or external vision/review tools.
- Do not reuse old R4 workers.
- Do not overwrite any slide artifacts.
- Do not broaden production beyond the R5 package split until the brief-ownership rule passes.
- Do not treat R4 as a clean mechanism pass.
## Current Archive Updates Already Made
The current session already updated:
```text
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
```
These files record:
- `S-02`, `S-03`, and `S-04` images are user accepted.
- R4 has a brief-ownership mechanism issue.
- R4 has a `S-04` sequencing warning.
- Broad production remains paused until the mechanism decision is made.
The user plans to manually commit all current changes after this handoff is written.

View File

@ -0,0 +1,249 @@
# R6 Notification/Wakeup And S-16 Repair Handoff
Date: 2026-06-24
Project:
```text
projects/2026-06-23-在路上
```
Task:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency
```
## Status
The polling-based slide workflow trial is basically complete.
Do not repair any image in the current session. The user plans to commit the current project state and start a fresh session for R6.
Latest user decision:
- `session-08` mechanically passed the 4-slide package test.
- `s16-v2-image.png` is not visually accepted.
- No repair should be done before the next session.
- R6 should replace polling with notification/wakeup behavior:
- main session sends task and exits;
- child session completes work;
- child/session completion activates or wakes the main session.
- R6 should also redo `S-16`.
## Read First In R6
Read these before acting:
```text
AGENTS.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-08/child-session-handoff.md
```
Use this handoff as the R6 task entrypoint after the user commits current work.
## Mechanism Summary
The current successful production boundary is:
1. A clean user-visible child session owns brief and packet generation.
2. The child session scans slide folders and resolves append-only next versions.
3. The child session writes and confirms `sNN-vN-brief.md` plus `session-XX/packets/sNN-vN-slide-agent-packet.md`.
4. Only then does it launch one internal one-shot slide worker.
5. The worker writes prompt/image/return only.
6. Review remains disabled unless the task explicitly asks for it.
Keep this boundary in R6.
Do not reuse closed workers from prior sessions.
## Context And Timing Results
Observed context/timing from recent package tests:
| Session | Scope | Result | User-observed context | Time |
| --- | --- | --- | --- | --- |
| `session-06` | `S-07`, then `S-08/S-09` | successful outputs accepted; `s08-v2` preserved as incomplete transport-failure evidence and retried as `s08-v3` | about `187K` by end | package observations included `S-07` at `12m22s`; Package 2 at `35m3s` with reconnect |
| `session-07` | `S-11/S-12/S-13` | completion gate pass; all three images accepted | `157K` | `30m5s` |
| `session-08` | `S-15/S-16/S-17/S-18` | completion gate pass; `S-16` image rejected | not reported in current session | thread duration about `36m16s`; child handoff visible span about `32m12s` |
These numbers are user/runtime observations, not child-session self-reported token counts. Child sessions could not see their own context usage.
## R6 Primary Goal
Test real notification/wakeup behavior instead of polling.
Required behavior:
```text
main session sends task -> main session exits / stops waiting
child session completes task -> completion activates or wakes main session
main session resumes and reads compact handoff
```
Do not simulate this with hidden parent polling.
In the new session, first discover whether the app exposes a real notification, automation, wakeup, or thread-resume tool. Use `tool_search` for likely tool names such as:
```text
automation_update
wakeup
notification
send_message_to_thread
read_thread
create_thread
spawn_agent
```
If a real activation/wakeup mechanism is unavailable, record a blocker and stop rather than continuing with ordinary polling while calling it notification.
## R6 Slide Scope
Use R6 to redo:
```text
S-16
```
Expected next version if no new `S-16` files are added before R6:
```text
s16-v3
```
But R6 must scan `projects/2026-06-23-在路上/slides/s16/` and resolve the next unused version before writing.
Do not overwrite:
```text
projects/2026-06-23-在路上/slides/s16/s16-v2-*
```
## S-16 Failure Record
`s16-v2-image.png` failed visual acceptance.
User-provided reason:
```text
没有达成:横向大远景,路从画面一侧切向远方,人物极小。
与 s15 的区别不大。
```
R6 repair target:
- horizontal extreme wide shot;
- road cuts from one side of the frame toward the far distance;
- traveler is extremely small;
- image must clearly differ from `S-15`;
- preserve landscape-led road documentary / poetic realism;
- do not turn the traveler into a portrait or medium-body subject.
Useful current artifacts:
```text
projects/2026-06-23-在路上/slides/s15/s15-v2-image.png
projects/2026-06-23-在路上/slides/s16/s16-v2-image.png
projects/2026-06-23-在路上/slides/s16/s16-v2-prompt.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-08/child-session-handoff.md
```
Treat `s15-v2-image.png` as a contrast reference for what `S-16` should not repeat too closely.
## Required Production Route
For the S-16 repair prompt:
- Use the `gpt-image-2` Skill Advisor / host-native workflow.
- Run the mode check:
```powershell
node C:\Users\wangq\.agents\skills\gpt-image-2\scripts\check-mode.js --json
```
- Read the relevant `gpt-image-2` template/reference before drafting.
- Record the Skill mode, template/reference path, and source files actually read.
- Use:
```text
projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md
projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md
```
- Load actual image references into visible generation context when character continuity matters.
- A local path in prompt text is traceability only; it does not count as loading the reference.
## R6 Suggested Task Shape
Recommended R6 scope:
```text
running mode: prompt and generate
scope: S-16 only
review: none unless user explicitly asks
overwrite allowed: no
main-session mechanism focus: notification/wakeup, not image batch throughput
completion gate: required
```
Suggested child-session path:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-09/
```
Use a new clean visible child session unless the notification/wakeup tool contract requires another carrier. If a different carrier is needed, record why.
## Completion Gate For R6
The child/session handoff must include:
- notification/wakeup mechanism used, or blocker if unavailable;
- whether main session truly stopped waiting before child completion;
- slide version resolved by folder scan;
- brief and packet child-owned before worker launch;
- worker id;
- prompt/image/return paths;
- image hash;
- review mode/result;
- no overwrite;
- no duplicate worker;
- no review file if review is disabled;
- context usage if visible, otherwise parent/user observation field;
- parent inspection recommendation.
## Non-Goals
- Do not repair `S-16` in the current session.
- Do not overwrite `s16-v2`.
- Do not run another polling-based package and call it notification.
- Do not broaden to more slides unless the user explicitly changes the R6 scope.
- Do not invoke CCPE.
- Do not call Minimax MCP or external vision/review tools unless explicitly authorized.
## Current File Updates Already Made
The current session updated:
```text
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
```
These files record:
- package-size trials through 4 slides;
- `session-07` 3-slide package accepted with context `157K` and time `30m5s`;
- `session-08` 4-slide package flow gate pass;
- `s16-v2` visual failure and deferred repair;
- R6 direction: notification/wakeup plus S-16 append-only repair.

View File

@ -0,0 +1,238 @@
# 人物一致性流程第三次测试交接
## 目的
本交接用于下一轮人物一致性流程测试。第三次测试的重点不是图片质量,而是验证 `session / SubAgent` 机制是否清晰、可追踪、不会重复启动 worker、不会覆盖已有产物。
本交接不是 CCPE 调用包,不启动外部 reviewer。
## 当前结论
- 第二轮测试已经结束,`s21-v3`、`s14-v2`、`s25-v2` 图片均已由用户确认可接受。
- 质量链路基本修复:提示词使用 `gpt-image-2` Advisor使用 style 母版,使用人物锚板 / 裁切 / 可见参考图,且 review 在明确禁用时没有生成。
- 流程链路仍有缺陷:`s14-v2` 出现两个 `Agent S-14` worker 指向同一组输出目标,说明 child session 内部缺少唯一 worker / 目标占用校验。
- 第二轮 brief 子会话在完成两个镜头后上下文占用达到约 83%,所以当前项目的人物一致性任务不应继续按 3 个镜头分配。
## 必读文件
先读这些仓库规则和工作流:
```text
AGENTS.md
VIDEO_WORKBENCH.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
```
再读项目和任务状态:
```text
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
```
再读第二轮真实产物记录:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-03/child-session-handoff.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-03/child-session-continuation-s14-s25-handoff.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-03/returns/s21-v3-slide-agent-return.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-03/returns/s14-v2-slide-agent-return.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-03/returns/s25-v2-slide-agent-return.md
```
## 已知 Session / Agent 记录
不要复用:
```text
019ef77d-552b-7343-abe4-88921b35d7ea
```
历史记录:
```text
session-02 child-session id: 019ef7ca-413a-7662-9633-7fb126b7ef35
session-03 child thread id: 019ef7d2-1a7f-7a90-8c04-0098239dfe0f
session-03 Agent S-21 thread id: 019ef7d6-3ff6-7213-b68c-fd646e39f1d2
session-03 recorded Agent S-14 thread id: 019ef803-95d7-7411-8d3c-c7f2f68a32e7
session-03 duplicate Agent S-14 observed by parent: 019ef803-328a-7e40-a0b0-0333c6b5fc6c
session-03 Agent S-25 thread id: 019ef803-e757-7041-8f4a-fc9dfce23bbd
```
第三次测试建议新建 `session-04`,不要继续使用 `session-03`,除非用户明确要测试旧 child session 的续跑能力。
## 机制边界
第三次测试要明确区分两个层级:
```text
用户可见 Codex child session:
- 用于 brief / orchestration / 分配工作。
- 会在窗口中多出用户可以看见的对话。
- 必须记录 session id。
- 本项目人物一致性任务最多分配 2 个可见人物镜头。
内部 SubAgent / one-shot slide worker:
- 由 child session 内部启动。
- 用户不需要在窗口中看到单独对话。
- 每个 SubAgent 只处理 1 个镜头。
- 完成后即结束,不做 idle / 长期复用。
- 必须把返回结果写入对应 return 文件。
```
第二轮的问题之一是 slide agent 仍以线程级 agent 形式出现。第三轮要重点验证 child session 是否能在内部使用 SubAgent而不是继续创建用户可见的 slide-agent 线程。
## 第三次测试建议范围
启动前由用户指定镜头;不要默认继续 `s21`、`s14`、`s25`,这三个已经完成验收。
建议范围:
```text
2 个可见人物 / identity-heavy 镜头
```
原因:
- 项目级规则已经改为人物一致性 child session 最多 2 个镜头;
- 2 个镜头足以验证 child session 内部是否启动了两个独立 SubAgent
- 也足以验证是否会重复启动同一个 slide/version worker
- 不会再次把 brief child session 推到过高上下文占用。
如果用户想同时测试版本扫描,可以选择:
```text
1 个已有 broad-run v1 但未完成规范 task 产物的镜头
1 个尚未进入人物一致性测试的镜头
```
具体 slide id 以用户下一步指令为准。
## 第三次测试必须验证
session 层:
- 是否创建了新的用户可见 child session。
- 是否记录了 child session id。
- 是否没有复用废弃 id `019ef77d-552b-7343-abe4-88921b35d7ea`
- 是否没有继续复用 `session-03`,除非用户明确授权。
- child session 是否只承担 brief / orchestration / 分配职责。
- child session 是否在每个 slide 前后记录上下文占用或至少记录是否接近暂停阈值。
SubAgent 层:
- child session 是否为每个 slide 启动一个内部一次性 SubAgent。
- 两个 slide 是否对应两个不同 SubAgent。
- SubAgent 是否没有出现在用户可见线程列表中;如果出现,说明机制不符合本轮目标。
- 每个 SubAgent 是否只处理一个 slide。
- 是否没有继续使用 `Agent S-21`、`Agent S-14`、`Agent S-25` 的旧上下文。
唯一性层:
- 一个 `slide_id + version` 是否只有一个 owning worker。
- child session 是否在启动 SubAgent 前写下 worker ledger。
- child session 是否在启动前检查目标文件不存在。
- child session 是否在写 prompt / image / return 前再次检查目标文件没有被占用。
- 是否没有出现两个 worker 使用同一个 packet 或同一组 target paths。
质量保底层:
- prompt 是否仍通过 `gpt-image-2` Skill Advisor / host-native 工作流生成。
- prompt 是否记录 mode、template/reference、实际读取的源文件。
- prompt 是否正确使用 `visual-system/style/style-prompt-master.md`
- prompt 是否正确使用 `visual-system/characters/character-reference-registry.md` 和当前人物参考图。
- visible identity 镜头是否加载真实人物参考图,而不是纯文本描述。
- 如果明确禁用 review则不得生成 review 文件。
## 建议新增记录结构
第三轮建议使用 `session-04`
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-04/child-session-plan.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-04/worker-launch-ledger.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-04/child-session-handoff.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-04/packets/sNN-vN-slide-agent-packet.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-04/returns/sNN-vN-slide-agent-return.md
```
`worker-launch-ledger.md` 至少记录:
```text
slide_id
resolved_version
worker_logical_name
carrier_type: internal SubAgent
visible_thread_id: none expected
target brief path
target prompt path
target image path
target return path
target review path: disabled / enabled
prelaunch target existence check
launch status
return status
parent verification status
```
## 启动前防重复检查
对每个待跑镜头child session 必须先扫描:
```text
projects/2026-06-23-在路上/slides/sNN/sNN-v*-*
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-*/packets/sNN-v*-slide-agent-packet.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-*/returns/sNN-v*-slide-agent-return.md
```
然后解析下一个未使用版本号。任何计划写入的文件已经存在时必须停下,不得覆盖。
## 暂停点
建议第三次测试继续分成两段:
```text
第一段:
- 新建 session-04 child session。
- 跑用户指定的第 1 个镜头。
- 验证 child session id、内部 SubAgent、ledger、版本扫描、防覆盖、prompt 证据。
- 产图后暂停,等用户确认图片和机制。
第二段:
- 在同一个 session-04 child session 内继续第 2 个镜头。
- child session 必须启动新的内部 SubAgent。
- 验证不是复用第 1 个 SubAgent。
- 产图后暂停,等用户确认。
```
如果第一段发现 slide agent 仍然变成用户可见线程,先不要继续第二段,应该先定位 Codex 当前可用的 subagent 工具形态。
## 完成时父会话必须检查
父会话不能只相信 child handoff。完成后要核对
- 用户可见 child session id 是否只有预期的一个新 child session。
- 是否没有额外用户可见 slide-agent 线程。
- worker ledger 中的 worker 数量是否等于 slide 数量。
- 每个 slide/version 是否只有一个 packet、一个 prompt、一个 image、一个 return。
- return 文件记录的 source worker 是否和 ledger 一致。
- review 文件是否符合任务设置。
- `task-plan.md`、`task-log.md`、`slides/slides.md` 是否更新为“图片结果”和“机制结果”两个维度。
## 结束判定
第三次测试只有在以下条件同时满足时,才能称为 session/SubAgent 机制通过:
- 新 child session id 已记录。
- child session 内部启动的 worker 数量等于测试镜头数。
- 每个 worker 都是一次性 SubAgent每个只处理一个镜头。
- 没有重复 worker 指向同一个 `slide_id + version`
- 没有覆盖任何旧产物。
- prompt 仍走 Advisor + style + 人物参考图链路。
- 用户确认生成图可接受,或即使图不接受,也能清楚区分是质量问题而不是机制问题。
如果出现重复 worker、可见线程污染、目标路径混用、return 来源不一致,第三次测试应记录为“机制未通过”,不要扩大到批量生产。

View File

@ -0,0 +1,294 @@
# Character Consistency Slide Task Handoff
## Status
- Date: 2026-06-24.
- Project: `projects/2026-06-23-在路上`.
- Purpose: prepare the next session to test the new local slide task orchestration workflow with the five character-consistency slides.
- Current state: workflow rules and templates have been drafted and promoted into workspace rules, but the actual character-consistency task directory has not been created yet.
This handoff is not a CCPE invocation. It is for local Video Workbench slide task orchestration.
## Current Uncommitted Workflow Changes
At the time this handoff was written, these workflow changes are in the working tree:
```text
AGENTS.md
VIDEO_WORKBENCH.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
docs/workflows/slide-task-orchestration-plan.md
```
Check `git status --short` before continuing.
## Must Read First
Read in this order:
1. `AGENTS.md`
- UTF-8 rules.
- `gpt-image-2` Skill Advisor workflow.
- task-level authorization rule.
- local slide task workflow rules.
2. `VIDEO_WORKBENCH.md`
- project layout.
- `slides/sNN/sNN-vN-type.ext` naming.
- `tasks/` orchestration model.
- reference-capable generation rule.
3. `docs/workflows/slide-task-orchestration.md`
- active main session / child session / slide agent contract.
4. `docs/workflows/slide-task-templates.md`
- exact task, child-session, packet, return, brief, prompt, and review structures.
5. `projects/2026-06-23-在路上/project.md`
6. `projects/2026-06-23-在路上/execution-plan.md`
7. `projects/2026-06-23-在路上/visual-system/visual-system.md`
8. `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md`
9. `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
10. `projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md`
11. `projects/2026-06-23-在路上/slides/slides.md`
12. `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
## Task To Create Next
Use this task directory:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/
```
Worker profile:
```text
video-slide-production
```
Default slide scope:
```text
s05
s21
s14
s25
s33
```
Default child-session split:
```text
session-01: s05 -> s21 -> s14
session-02: s25 -> s33
```
Run child sessions sequentially. Do not parallelize.
## Required User Instruction Before Starting
The next main session should ask for or receive a concrete task running mode before creating prompts or generating images:
```text
prompt only
```
or:
```text
prompt and generate
```
If the mode is `prompt only`:
- create `task-plan.md`;
- create child-session plans;
- write `sNN-v1-brief.md`;
- create slide-agent packets;
- have slide agents write `sNN-v1-prompt.md`;
- do not generate images.
If the mode is `prompt and generate`:
- record the mode and exact slide scope in `task-plan.md`;
- create briefs and prompts;
- load required character reference images before generation;
- generate new images only for the authorized scope;
- write review files only where required.
## Current Slide-Specific Context
The five test slides are from:
```text
projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md
```
Purpose:
> Let the audience believe that the traveler remains the same person through back view, side/back action, half-profile, hand/body detail, and restrained emotional close-up.
Recommended order:
```text
s05 -> s21 -> s14 -> s25 -> s33
```
Slide roles:
| Slide | Function | Identity risk |
| --- | --- | --- |
| `s05` | backpack / coat / back silhouette baseline | medium human |
| `s21` | side/back motion, backpack adjustment, fire direction | medium human |
| `s14` | half-profile tired dignity in city edge | close / face human |
| `s25` | hand/body dust action and face edge | close / detail human |
| `s33` | restrained emotional half-profile | close / face human |
## Old Broad-Run Images
The following images already exist from the flawed broad run:
```text
slides/s05/s05-v1-image.png
slides/s14/s14-v1-image.png
slides/s21/s21-v1-image.png
slides/s25/s25-v1-image.png
slides/s33/s33-v1-image.png
```
Do not treat them as accepted finals.
Use them only as comparison or failure context unless the user explicitly asks to salvage one.
The broad-run failure was:
- no per-slide brief;
- no per-slide prompt;
- text-only character description;
- accepted character reference images were not actually loaded;
- high-risk identity slides drifted.
## Visual-System Requirements
The child session and slide agent must use active `visual-system/` materials.
Style:
```text
projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md
```
Character:
```text
projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md
```
Rules:
- Style prompt language must come from the active style master.
- Character references must be selected from the active character registry.
- Visible character identity must not be generated from text-only prompts.
- For near / identity-heavy slides, prefer matching crop references.
- For back / side / walking slides, prefer matching crop or transparent slice by visible direction.
- The prompt must name loaded reference roles such as `Image 1: identity reference`.
## Expected Per-Slide Artifacts
For each slide:
```text
slides/sNN/sNN-v1-brief.md
slides/sNN/sNN-v1-prompt.md
```
If generation is authorized and succeeds:
```text
slides/sNN/sNN-v1-image.png
```
If review is required:
```text
slides/sNN/sNN-v1-review.md
```
Review is expected for this character-consistency test if images are generated, because these slides are identity-sensitive.
## Expected Task Artifacts
Task root:
```text
task-plan.md
task-log.md
```
Session 01:
```text
session-01/child-session-plan.md
session-01/child-session-handoff.md
session-01/packets/s05-v1-slide-agent-packet.md
session-01/packets/s21-v1-slide-agent-packet.md
session-01/packets/s14-v1-slide-agent-packet.md
session-01/returns/s05-v1-slide-agent-return.md
session-01/returns/s21-v1-slide-agent-return.md
session-01/returns/s14-v1-slide-agent-return.md
```
Session 02:
```text
session-02/child-session-plan.md
session-02/child-session-handoff.md
session-02/packets/s25-v1-slide-agent-packet.md
session-02/packets/s33-v1-slide-agent-packet.md
session-02/returns/s25-v1-slide-agent-return.md
session-02/returns/s33-v1-slide-agent-return.md
```
## Do Not Do
- Do not invoke CCPE for this workflow.
- Do not ask GPT V2 for final prompts.
- Do not use Minimax MCP for review by default.
- Do not generate visible-character identity slides from text-only prompts.
- Do not use archived character or style files unless a packet explicitly reopens them.
- Do not process multiple slides inside one slide agent.
- Do not run child sessions or slide agents in parallel.
- Do not treat old broad-run images as accepted finals.
## Suggested Next User Message
The next user can start with:
```text
Use slide task orchestration for projects/2026-06-23-在路上.
Task: character consistency test.
Worker profile: video-slide-production.
Mode: prompt only.
Slides: s05, s21, s14, s25, s33.
Split: session-01 s05/s21/s14, session-02 s25/s33.
Create the task records and run session-01 sequentially.
```
If the user wants image generation in the same task, replace `Mode: prompt only` with:
```text
Mode: prompt and generate.
```
## Verification Before Starting
Before starting the task, verify:
```powershell
git status --short
Test-Path -LiteralPath 'docs/workflows/slide-task-orchestration.md'
Test-Path -LiteralPath 'docs/workflows/slide-task-templates.md'
Test-Path -LiteralPath 'projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md'
Test-Path -LiteralPath 'projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md'
Test-Path -LiteralPath 'projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md'
```

View File

@ -0,0 +1,255 @@
# Character Consistency Workflow Review Handoff
## Status
- Date: 2026-06-24.
- Project: `projects/2026-06-23-在路上`.
- Task: `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/`.
- Purpose: hand off after the first `s05` character-consistency workflow test and workflow-rule correction.
- Current state: superseded by later workflow-reset decision before `s21`.
## Supersession Note
Later user decision:
- do not continue child-session agent `019ef77d-552b-7343-abe4-88921b35d7ea`;
- treat the previous `s05` run as useful but procedurally defective because it overwrote an existing broad-run `s05-v1-image.png`;
- patch the workflow docs and local task records before running `s21`;
- future task execution must append the next unused slide version and must not overwrite existing slide artifacts.
The original continuation suggestion below is historical context only. Do not use it as the active next-step plan.
This handoff is not a CCPE invocation. It is for local Video Workbench slide task orchestration continuation.
## Current User Decision
The user accepted the generated `s05` image as usable:
```text
projects/2026-06-23-在路上/slides/s05/s05-v1-image.png
```
Do not regenerate `s05` unless the user explicitly asks for another sample.
## Workflow Files Updated This Turn
Updated:
```text
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
```
New handoff:
```text
handoff/2026-06-24-character-consistency-workflow-review-handoff.md
```
The workflow docs now clarify:
- `gpt-image-2` is used as Advisor for prompt/spec construction in Video Workbench.
- Normal project-bound generation does not need to prove Garden/API execution.
- Expected generation evidence is:
- Advisor prompt/spec record;
- actual local reference image loaded into visible conversation context when references matter;
- host built-in image generation called with the loaded image assigned a role such as `Image 1`;
- host generated-image source path;
- copied project image path;
- review or return evidence.
- `Garden/API expected: no` is the default unless the user explicitly changes the project policy.
## Must Read First In Next Session
Read in this order:
1. `AGENTS.md`
2. `VIDEO_WORKBENCH.md`
3. `docs/workflows/slide-task-orchestration.md`
4. `docs/workflows/slide-task-templates.md`
5. `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md`
6. `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md`
7. `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-01/child-session-plan.md`
8. `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-01/child-session-handoff.md`
9. `projects/2026-06-23-在路上/slides/s05/s05-v1-brief.md`
10. `projects/2026-06-23-在路上/slides/s05/s05-v1-prompt.md`
11. `projects/2026-06-23-在路上/slides/s05/s05-v1-review.md`
12. `projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-01/returns/s05-v1-slide-agent-return.md`
13. `projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md`
14. `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md`
15. `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
16. `investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md`
## Active Agent / Session IDs
Deprecated child-session agent:
```text
session-01 child-session agent id: 019ef77d-552b-7343-abe4-88921b35d7ea
```
Do not reuse this child-session id for the `s21` reset test.
Completed `s05` slide-agent:
```text
s05 slide-agent id: 019ef781-1ff1-7073-80b0-3cf688104cdb
```
Earlier recommendation to continue this child-session is obsolete.
## What Happened In The S05 Test
Planned architecture:
```text
main session
-> child session
-> slide agent
-> prompt
-> visible-context reference load
-> host image_gen
-> review / return
```
Actual architecture:
```text
main session
-> child session wrote s05 brief and packet
-> main session directly started s05 slide-agent
-> slide-agent wrote prompt, image, and review
```
This means the `s05` test did not fully validate child-session-owned slide-agent spawning.
Original next-test recommendation, now obsolete:
- do not send `s21` to child-session agent `019ef77d-552b-7343-abe4-88921b35d7ea`;
- start a new child-session agent instead;
- require that child session itself starts the `s21` slide-agent if the runtime supports it;
- if the child session cannot spawn the slide-agent, it must record `runtime fallback required`;
- only then should main session start the slide-agent as fallback.
## Problems Found This Turn
### 1. Main Session Started Slide-Agent Directly
The main session directly started `s05` slide-agent instead of requiring the child session to do it.
Impact:
- `s05` asset is usable.
- Workflow test is incomplete for the planned three-layer orchestration.
- The next session must test the intended child-session-owned slide-agent launch.
### 2. Interrupted Return Mismatch
After `s05-v1-prompt.md` appeared, the main session assumed the slide-agent might be stuck and interrupted it.
Later evidence showed:
- `s05-v1-image.png` had already been generated and copied;
- `s05-v1-review.md` had already been written;
- the first return text incorrectly said generation was blocked.
This was reconciled in:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-01/returns/s05-v1-slide-agent-return.md
projects/2026-06-23-在路上/slides/s05/s05-v1-review.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
```
Next-session rule:
- do not interrupt a slide-agent just because the prompt appeared first;
- check for image, review, generated-image source, and return before interrupting;
- if interrupting is necessary, inspect files after interruption before writing conclusions.
### 3. Advisor / Garden/API Boundary Was Ambiguous In Agent Reasoning
The workflow had already intended:
```text
gpt-image-2 Advisor for prompt/spec
host image_gen for actual generation
```
But the review language drifted toward treating "not proving Garden/API" as a possible evidence gap.
This is wrong for current Video Workbench policy.
Correct rule:
```text
Garden/API expected: no
```
Unless the user explicitly changes the project policy.
The updated workflow docs now make this explicit.
### 4. Review Was Generated Without Task-Plan Clarity
The user did not separately request review, but the packet allowed review after generation and identity-sensitive generated trials should default to local review.
Next-session rule:
- task plan or packet should explicitly say whether review is required;
- character-consistency / identity-sensitive generation defaults to local review unless disabled.
## S05 Asset Summary
Generated image:
```text
projects/2026-06-23-在路上/slides/s05/s05-v1-image.png
```
Generated host source:
```text
C:\Users\wangq\.codex\generated_images\019ef781-1ff1-7073-80b0-3cf688104cdb\ig_087687f122f488ef016a3b446bd4fc8198bf390912b8aeb494.png
```
Main-session alternate reference-check candidate was generated but not copied into the project:
```text
C:\Users\wangq\.codex\generated_images\019ef76c-7bc1-7550-91ce-51acd8d699f2\ig_064460e17256e2f6016a3b45364f20819abd5e6d125d5e7c5c.png
```
The project image hash matched the slide-agent generated host source during verification.
## Recommended Next User Message
```text
Continue character consistency workflow test.
Start a new child-session agent. Do not reuse:
019ef77d-552b-7343-abe4-88921b35d7ea
Next slide: s21.
Mode: prompt and generate.
Review: disabled for this test.
Artifact policy: append next unused s21-vN version; overwrite allowed: no.
This time require the child session to start the s21 slide-agent itself.
If the child session cannot spawn the slide-agent, record runtime fallback required and stop for main-session fallback.
Use updated docs/workflows rules.
Do not regenerate s05.
```
## Verification Before Continuing
Before continuing, verify:
```powershell
git status --short
Test-Path -LiteralPath 'docs/workflows/slide-task-orchestration.md'
Test-Path -LiteralPath 'docs/workflows/slide-task-templates.md'
Test-Path -LiteralPath 'projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md'
Test-Path -LiteralPath 'projects/2026-06-23-在路上/slides/s05/s05-v1-image.png'
Test-Path -LiteralPath 'projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md'
```

View File

@ -0,0 +1,37 @@
watched_paths:
- "2026-06-24-on-the-road-style-reference-handoff.md"
status_fields:
- status
- lifecycle
forbidden_status_values:
- stable
- accepted
- final
- released
- production-ready
warning_status_values:
- active
- completed
- complete
approved_phrases:
- owner-approved
- ccra-approved
- production-ready
- released
- final
- accepted
- 已接受
- 已验证
- 完成
required_evidence_markers:
- evidence
- Evidence
- user
- User
- 用户
allowed_contexts:
- "not accepted"
- "not accepted finals"
- "Do not"
- "不"
- "候选"

View File

@ -0,0 +1,37 @@
{
"scan_root": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench\\handoff",
"config_path": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench\\handoff\\2026-06-24-on-the-road-style-reference-context\\lifecycle-guard-config.yaml",
"files_scanned": [
"2026-06-24-on-the-road-style-reference-handoff.md"
],
"possible_overclaims": [],
"field_level_findings": [],
"phrase_level_findings": [],
"missing_evidence_markers": [],
"warnings": [],
"blocking_errors": [],
"observations": [
{
"file": "2026-06-24-on-the-road-style-reference-handoff.md",
"source": "text",
"phrase": "accepted",
"line": 168,
"column": 100,
"severity": "observation",
"evidence_present": true,
"context": "ter.md` exists? - Should `style-blueprints-contactsheet.png` remain active for quick visual inspection, or become archived process evidence? - Should style modules reference source images from `intake/imgs/` directly, or only reference the accepted style board and C repair image? ## Verification Commands Already Run In This Handoff ```powershell git status --short ``` Result before creating this handoff: clean. ```powershell python C:\\Users\\wangq\\.agents\\skills\\review-context-bui",
"message": "Approval claim phrase has nearby evidence marker; approval validity is not decided by this scan.",
"kind": "evidence_present_claim"
}
],
"machine_readable_summary": {
"status": "PASS",
"files_scanned_count": 1,
"field_finding_count": 0,
"phrase_finding_count": 0,
"missing_evidence_count": 0,
"warning_count": 0,
"blocking_count": 0,
"observation_count": 1
}
}

View File

@ -0,0 +1,25 @@
# Lifecycle Status Guard Scan
## Summary
- Status: `PASS`
- Files scanned: 1
- Blocking findings: 0
- Warnings: 0
- Evidence-present observations: 1
## Blocking Findings
- None
## Warnings
- None
## Observations
- `2026-06-24-on-the-road-style-reference-handoff.md` line 168: `accepted` - evidence marker present; approval validity not decided.
## Files Scanned
- `2026-06-24-on-the-road-style-reference-handoff.md`

View File

@ -0,0 +1,89 @@
# Review Context
This context is an index. It does not replace reading source files.
## Metadata
- Review ID: `2026-06-24-on-the-road-style-reference-handoff`
- Context profile: `handoff`
- Status: `PASS`
## Source Roots
- `VIDEO_WORKBENCH.md`
- `AGENTS.md`
- `projects/2026-06-23-在路上/project.md`
- `projects/2026-06-23-在路上/execution-plan.md`
- `projects/2026-06-23-在路上/visual-system/visual-system.md`
- `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
- `projects/2026-06-23-在路上/visual-system/style`
- `projects/2026-06-23-在路上/slides/slides.md`
- `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
- `projects/2026-06-23-在路上/slides/s01/s01-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s10/s10-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s47/s47-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md`
## Files Included
- `AGENTS.md` (3034 bytes)
- `VIDEO_WORKBENCH.md` (9310 bytes)
- `projects/2026-06-23-在路上/execution-plan.md` (4361 bytes)
- `projects/2026-06-23-在路上/project.md` (3774 bytes)
- `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md` (9926 bytes)
- `projects/2026-06-23-在路上/slides/s01/s01-v1-prompt.md` (8298 bytes)
- `projects/2026-06-23-在路上/slides/s10/s10-v1-prompt.md` (11212 bytes)
- `projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md` (10452 bytes)
- `projects/2026-06-23-在路上/slides/s47/s47-v1-prompt.md` (8134 bytes)
- `projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md` (8039 bytes)
- `projects/2026-06-23-在路上/slides/slides.md` (10429 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md` (3093 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-board-review-v1.md` (2499 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-board-spec-v1.md` (6588 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-board-v1.html` (9775 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-brief-v1.md` (11432 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-prompt-v1.md` (8004 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-review-v1.md` (3752 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-trial-plan.md` (5523 bytes)
- `projects/2026-06-23-在路上/visual-system/visual-system.md` (7343 bytes)
## Files Excluded
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-board-v1.png`: size_exceeds_limit, 2762536 bytes
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-v1.png`: size_exceeds_limit, 3874057 bytes
- `projects/2026-06-23-在路上/visual-system/style/style-blueprints-contactsheet.png`: size_exceeds_limit, 1844737 bytes
## Important Reports
- `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-board-review-v1.md`
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-review-v1.md`
## Test Or Validation Outputs
- None
## Diff Or Changed File References
- None
## Prior Decision References
- None
## Known Non Goals
- None
## Open Questions For Reviewer Or Agent
- None
## Blocking Errors
- None
## Machine Readable Manifest
- `review-file-manifest.json`

View File

@ -0,0 +1,165 @@
{
"review_id": "2026-06-24-on-the-road-style-reference-handoff",
"context_profile": "handoff",
"project_root": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench",
"source_roots": [
"VIDEO_WORKBENCH.md",
"AGENTS.md",
"projects/2026-06-23-在路上/project.md",
"projects/2026-06-23-在路上/execution-plan.md",
"projects/2026-06-23-在路上/visual-system/visual-system.md",
"projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md",
"projects/2026-06-23-在路上/visual-system/style",
"projects/2026-06-23-在路上/slides/slides.md",
"projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md",
"projects/2026-06-23-在路上/slides/s01/s01-v1-prompt.md",
"projects/2026-06-23-在路上/slides/s10/s10-v1-prompt.md",
"projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md",
"projects/2026-06-23-在路上/slides/s47/s47-v1-prompt.md",
"projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md"
],
"missing_source_roots": [],
"files_included": [
{
"path": "AGENTS.md",
"size_bytes": 3034,
"source_root": "AGENTS.md"
},
{
"path": "VIDEO_WORKBENCH.md",
"size_bytes": 9310,
"source_root": "VIDEO_WORKBENCH.md"
},
{
"path": "projects/2026-06-23-在路上/execution-plan.md",
"size_bytes": 4361,
"source_root": "projects/2026-06-23-在路上/execution-plan.md"
},
{
"path": "projects/2026-06-23-在路上/project.md",
"size_bytes": 3774,
"source_root": "projects/2026-06-23-在路上/project.md"
},
{
"path": "projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md",
"size_bytes": 9926,
"source_root": "projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md"
},
{
"path": "projects/2026-06-23-在路上/slides/s01/s01-v1-prompt.md",
"size_bytes": 8298,
"source_root": "projects/2026-06-23-在路上/slides/s01/s01-v1-prompt.md"
},
{
"path": "projects/2026-06-23-在路上/slides/s10/s10-v1-prompt.md",
"size_bytes": 11212,
"source_root": "projects/2026-06-23-在路上/slides/s10/s10-v1-prompt.md"
},
{
"path": "projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md",
"size_bytes": 10452,
"source_root": "projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md"
},
{
"path": "projects/2026-06-23-在路上/slides/s47/s47-v1-prompt.md",
"size_bytes": 8134,
"source_root": "projects/2026-06-23-在路上/slides/s47/s47-v1-prompt.md"
},
{
"path": "projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md",
"size_bytes": 8039,
"source_root": "projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md"
},
{
"path": "projects/2026-06-23-在路上/slides/slides.md",
"size_bytes": 10429,
"source_root": "projects/2026-06-23-在路上/slides/slides.md"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md",
"size_bytes": 3093,
"source_root": "projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-board-review-v1.md",
"size_bytes": 2499,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-board-spec-v1.md",
"size_bytes": 6588,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-board-v1.html",
"size_bytes": 9775,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-brief-v1.md",
"size_bytes": 11432,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-prompt-v1.md",
"size_bytes": 8004,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-review-v1.md",
"size_bytes": 3752,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-trial-plan.md",
"size_bytes": 5523,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/visual-system.md",
"size_bytes": 7343,
"source_root": "projects/2026-06-23-在路上/visual-system/visual-system.md"
}
],
"files_excluded": [
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-board-v1.png",
"reason": "size_exceeds_limit",
"size_bytes": 2762536
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-v1.png",
"reason": "size_exceeds_limit",
"size_bytes": 3874057
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-blueprints-contactsheet.png",
"reason": "size_exceeds_limit",
"size_bytes": 1844737
}
],
"important_reports": [
"projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md",
"projects/2026-06-23-在路上/visual-system/style/style-anchor-board-review-v1.md",
"projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-review-v1.md"
],
"test_or_validation_outputs": [],
"diff_or_changed_file_references": [],
"prior_decision_references": [],
"known_non_goals": [],
"open_questions_for_reviewer_or_agent": [],
"metadata": {},
"blocking_errors": [],
"machine_readable_summary": {
"status": "PASS",
"source_roots_count": 14,
"missing_source_roots_count": 0,
"files_included_count": 20,
"files_excluded_count": 3,
"important_reports_count": 3,
"validation_outputs_count": 0,
"diff_references_count": 0,
"prior_decisions_count": 0,
"blocking_error_count": 0
}
}

View File

@ -0,0 +1,186 @@
# On The Road Style / Reference Repair Handoff
## Status
- Date: 2026-06-24.
- Project: `projects/2026-06-23-在路上`.
- Current branch: `master`.
- Recent commits:
- `9b1a3c3` `visual-system/characters规则及清理`
- `4329653` `Broad-run images are candidates, not accepted finals. Identity/style reference workflow needs repair before further generation.`
- `c37e7ab` `Add accepted visual anchors and five-shot trial`
- Current handoff context index:
- `handoff/2026-06-24-on-the-road-style-reference-context/review-context.md`
- `handoff/2026-06-24-on-the-road-style-reference-context/review-file-manifest.json`
## User Decision
Use a fresh session. Do not rely on chat compression for the next phase.
The user corrected the reference policy:
- Person identity work must use image references.
- Do not downgrade identity-critical shots to text-only generation.
- The next identity test is not whether to use a reference at all; it is which active reference to use: master character anchor, front crop, side crop, back crop, walking crop, or transparent slice.
- Style references are different. The style board is useful, but style continuity may be better carried by a reusable prompt master plus visual calibration images rather than mandatory image-to-image for every shot.
## Must Read First
Read these in order before editing or generating:
1. `AGENTS.md`
- UTF-8 reading/writing rules.
- `gpt-image-2` workflow rule.
- Approval gate for project-bound image generation.
2. `VIDEO_WORKBENCH.md`
- `slides/sNN/sNN-vN-type.ext` naming rule.
- Character cleanup / archive rule.
- Project-bound image prompt rules.
3. `projects/2026-06-23-在路上/project.md`
- Project-local status and scope.
4. `projects/2026-06-23-在路上/execution-plan.md`
- Current execution strategy.
5. `projects/2026-06-23-在路上/visual-system/visual-system.md`
- Current visual system and A/B/C/D anchor definitions.
6. `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
- Active character references and selection rules.
7. `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
- Why broad generation is paused.
- What failed in the prior broad run.
8. Five-shot prompt/review evidence:
- `projects/2026-06-23-在路上/slides/s01/s01-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s01/s01-v1-review.md`
- `projects/2026-06-23-在路上/slides/s10/s10-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s10/s10-v1-review.md`
- `projects/2026-06-23-在路上/slides/s46/s46-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s46/s46-v1-review.md`
- `projects/2026-06-23-在路上/slides/s47/s47-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s47/s47-v1-review.md`
- `projects/2026-06-23-在路上/slides/s51/s51-v1-prompt.md`
- `projects/2026-06-23-在路上/slides/s51/s51-v1-review.md`
9. Style source files:
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-brief-v1.md`
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-board-review-v1.md`
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-review-v1.md`
The generated context index lists the same reading set and included/excluded files.
## Confirmed Evidence
Five core shot tests were not true image-reference generation. They used Mode B standalone prompt generation. The references were used for prompt construction, not attached as actual image inputs.
Evidence in review files:
| Shot | Evidence |
| --- | --- |
| `s01` | `s01-v1-review.md` says no character reference was used and image references were not attached. |
| `s10` | `s10-v1-review.md` says character/style references were read or viewed locally, and explicit image-reference attachment was not available. |
| `s46` | `s46-v1-review.md` says character/style references were read or viewed locally, and explicit image-reference attachment was not available. |
| `s47` | `s47-v1-review.md` says character/style references were read or viewed locally, and explicit image-reference attachment was not available. |
| `s51` | `s51-v1-review.md` says character/style references were read or viewed locally, and explicit image-reference attachment was not available. |
This means the five-shot visual trial can still be useful as visually approved-looking image results, but it does not prove that the character anchor or style board can control future scene generation through actual image-reference input.
## Completed Since The Broad-Run Failure
- Broad-run candidates were committed as candidates, not accepted finals.
- `slides/sNN/` files were renamed to the `sNN-v1-type.ext` convention.
- `s34` bookkeeping was repaired:
- `slides.md` marks `s34` as `generated`.
- `broad-generation-run-v1.md` has a backfilled `s34` entry.
- The project image hash matched the host output.
- `visual-system/characters/` was cleaned:
- Active references remain there.
- Historical/process files moved to `archive/characters/`.
- `character-reference-registry.md` now defines active references and selection rules.
## Current Style Directory State
`visual-system/style/` still contains both active assets and process files:
- `style-anchor-board-v1.png`
- `style-anchor-board-v1.html`
- `style-anchor-board-spec-v1.md`
- `style-anchor-board-review-v1.md`
- `style-anchor-brief-v1.md`
- `style-anchor-c-repair-v1.png`
- `style-anchor-c-repair-prompt-v1.md`
- `style-anchor-c-repair-review-v1.md`
- `style-anchor-trial-plan.md`
- `style-blueprints-contactsheet.png`
Likely active assets:
- `style-anchor-board-v1.png`: common style calibration board.
- `style-anchor-c-repair-v1.png`: visually useful C repair sample.
- A new style prompt master / registry file to be created.
Likely archive candidates after registry/master exists:
- trial plan, brief, board spec, board review, C repair prompt/review, HTML rendering file, and contactsheet if not needed as an active visual reference.
Do not archive style files before deciding and writing the active style registry / prompt master.
## Next Recommended Sequence
1. Build style registry / prompt master.
- Suggested path: `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md`
- It should define A/B/C/D modules, global style kernel, negative drift list, and how each module maps to shot types.
- It should also state which visual files remain active calibration references.
2. Then clean `visual-system/style/`.
- Create `archive/style/`.
- Keep only active style references and the new style prompt master in `visual-system/style/`.
- Move process files to `archive/style/`.
3. Repair prompt rules before any generation resumes.
- Each `sNN-vN-prompt.md` must include explicit `Reference Inputs`.
- Character references must be selected from `character-reference-registry.md`.
- Style prompt module must be selected from the new style master.
4. Run character reference validation tests.
- Test master anchor versus front/side/back/walking crops/slices.
- Required test set:
- side or half-face identity;
- back walking;
- side walking;
- medium human in environment.
- Do not continue broad generation until this test proves which active references work.
5. Only after the above, repair or regenerate high-risk shots from the broad run:
- `s14`
- `s33`
- `s21`
- `s05`
- `s25`
6. Then resume remaining missing shots.
## Do Not Do Next
- Do not continue from `s35` yet.
- Do not treat the five-shot trial as proof of character-reference control.
- Do not use archived character files as default references.
- Do not create identity-critical scene images using text-only character descriptions.
- Do not skip per-shot prompt/spec artifacts.
- Do not ask GPT V2 for final prompts; Codex owns local final prompt construction through the `gpt-image-2` workflow.
## Open Questions For Next Session
- Which actual generation path can attach local character reference images for identity-critical tests?
- Should `style-anchor-board-v1.html` remain active as an editable board source, or move to `archive/style/` after `style-prompt-master.md` exists?
- Should `style-blueprints-contactsheet.png` remain active for quick visual inspection, or become archived process evidence?
- Should style modules reference source images from `intake/imgs/` directly, or only reference the accepted style board and C repair image?
## Verification Commands Already Run In This Handoff
```powershell
git status --short
```
Result before creating this handoff: clean.
```powershell
python C:\Users\wangq\.agents\skills\review-context-builder\scripts\review_context_builder.py ...
```
Result: wrote the context index and manifest under:
```text
handoff/2026-06-24-on-the-road-style-reference-context/
```

View File

@ -0,0 +1,27 @@
watched_paths:
- "handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md"
- "handoff/2026-06-24-on-the-road-workflow-continuation-context/review-context.md"
- "handoff/2026-06-24-on-the-road-workflow-continuation-context/metadata.json"
status_fields:
- status
- lifecycle
forbidden_status_values:
- stable
- production-ready
- released
warning_status_values:
- accepted
- complete
required_evidence_markers:
- User decision
- user decision
- 用户决策
- prior_decisions
approved_phrases:
- owner-approved
- CCRA-approved
forbidden_phrases:
- production-ready
- released
allowed_contexts:
- "Do not"

View File

@ -0,0 +1,26 @@
{
"scan_root": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench",
"config_path": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench\\handoff\\2026-06-24-on-the-road-workflow-continuation-context\\lifecycle-guard-config.yaml",
"files_scanned": [
"handoff/2026-06-24-on-the-road-workflow-continuation-context/metadata.json",
"handoff/2026-06-24-on-the-road-workflow-continuation-context/review-context.md",
"handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md"
],
"possible_overclaims": [],
"field_level_findings": [],
"phrase_level_findings": [],
"missing_evidence_markers": [],
"warnings": [],
"blocking_errors": [],
"observations": [],
"machine_readable_summary": {
"status": "PASS",
"files_scanned_count": 3,
"field_finding_count": 0,
"phrase_finding_count": 0,
"missing_evidence_count": 0,
"warning_count": 0,
"blocking_count": 0,
"observation_count": 0
}
}

View File

@ -0,0 +1,27 @@
# Lifecycle Status Guard Scan
## Summary
- Status: `PASS`
- Files scanned: 3
- Blocking findings: 0
- Warnings: 0
- Evidence-present observations: 0
## Blocking Findings
- None
## Warnings
- None
## Observations
- None
## Files Scanned
- `handoff/2026-06-24-on-the-road-workflow-continuation-context/metadata.json`
- `handoff/2026-06-24-on-the-road-workflow-continuation-context/review-context.md`
- `handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md`

View File

@ -0,0 +1,19 @@
{
"known_non_goals": [
"Do not resume broad generation from s35 in the next session.",
"Do not redo API/Garden image-generation research for normal Video Workbench work.",
"Do not treat old text-only broad-run images as accepted finals.",
"Do not replace source-file reading with this context index."
],
"open_questions_for_reviewer_or_agent": [
"How should project.md and execution-plan.md be updated to close stale pre-S14 open questions?",
"What is the minimal per-shot production unit for the repaired workflow?",
"How should the old broad-run candidates for s05, s14, s21, s25, and s33 be marked or replaced?"
],
"prior_decisions": [
"Reference-capable generation path is gpt-image-2 Advisor prompt/spec, then load the real image into context, then host image_gen.",
"Normal Video Workbench image generation should not use API/Garden unless the user changes the policy.",
"Near identity-heavy shots prefer matching crops; distant landscape-led shots prefer the anchor board or project-approved distant reference.",
"For On The Road, transparent crops derived from the accepted character anchor board are enough by default for consistency."
]
}

View File

@ -0,0 +1,114 @@
# Review Context
This context is an index. It does not replace reading source files.
## Metadata
- Review ID: `2026-06-24-on-the-road-workflow-continuation`
- Context profile: `handoff`
- Status: `PASS`
## Source Roots
- `handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md`
- `handoff/2026-06-24-on-the-road-style-reference-handoff.md`
- `AGENTS.md`
- `VIDEO_WORKBENCH.md`
- `projects/2026-06-23-在路上/project.md`
- `projects/2026-06-23-在路上/execution-plan.md`
- `projects/2026-06-23-在路上/visual-system/visual-system.md`
- `projects/2026-06-23-在路上/visual-system/characters`
- `projects/2026-06-23-在路上/visual-system/style`
- `projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md`
- `projects/2026-06-23-在路上/slides/slides.md`
- `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
- `investigations/2026-06-24-s14-reference-capable-generation`
## Files Included
- `AGENTS.md` (3908 bytes)
- `VIDEO_WORKBENCH.md` (13590 bytes)
- `handoff/2026-06-24-on-the-road-style-reference-handoff.md` (8884 bytes)
- `handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md` (10648 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/README.md` (2545 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/generation-log.md` (3817 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/lifecycle-guard-config.yaml` (1065 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-anchor-board-reference-prompt.md` (4372 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-side-crop-reference-prompt.md` (4331 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/comparison-and-user-review.md` (2632 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-anchor-board-reference-review.md` (3069 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-side-crop-reference-review.md` (2960 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md` (4163 bytes)
- `investigations/2026-06-24-s14-reference-capable-generation/s14-reference-test-plan.md` (4861 bytes)
- `projects/2026-06-23-在路上/execution-plan.md` (4361 bytes)
- `projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md` (20628 bytes)
- `projects/2026-06-23-在路上/project.md` (3774 bytes)
- `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md` (9926 bytes)
- `projects/2026-06-23-在路上/slides/slides.md` (10429 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-back-reference-crop-tight.png` (514654 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-front-reference-crop-tight.png` (550634 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-front-reference-crop.png` (580097 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-side-reference-crop-tight.png` (448440 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-walk-back-reference-crop-tight.png` (387226 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-walk-side-reference-crop-tight.png` (514280 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-identity-lock.md` (5147 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md` (3093 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-slice-side-v2-from-anchor.png` (1056370 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-slice-walk-back-v2-from-anchor.png` (828824 bytes)
- `projects/2026-06-23-在路上/visual-system/characters/character-slice-walk-side-v2-from-anchor.png` (880680 bytes)
- `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md` (18881 bytes)
- `projects/2026-06-23-在路上/visual-system/visual-system.md` (7343 bytes)
## Files Excluded
- `investigations/2026-06-24-s14-reference-capable-generation/lifecycle-guard-output/lifecycle-status-guard-scan.json`: exclude_pattern
- `investigations/2026-06-24-s14-reference-capable-generation/lifecycle-guard-output/lifecycle-status-guard-scan.md`: exclude_pattern
- `investigations/2026-06-24-s14-reference-capable-generation/outputs/s14-anchor-board-reference-v1.png`: size_exceeds_limit, 3459163 bytes
- `investigations/2026-06-24-s14-reference-capable-generation/outputs/s14-side-crop-reference-v1.png`: size_exceeds_limit, 3639880 bytes
- `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-codex-posture-test.png`: size_exceeds_limit, 3834108 bytes
- `projects/2026-06-23-在路上/visual-system/characters/character-slice-back-v2-from-anchor.png`: size_exceeds_limit, 1255933 bytes
- `projects/2026-06-23-在路上/visual-system/characters/character-slice-front-v2-from-anchor.png`: size_exceeds_limit, 1328996 bytes
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-board-v1.png`: size_exceeds_limit, 2762536 bytes
- `projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-v1.png`: size_exceeds_limit, 3874057 bytes
## Important Reports
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/comparison-and-user-review.md`
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-anchor-board-reference-review.md`
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-side-crop-reference-review.md`
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md`
- `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
## Test Or Validation Outputs
- `investigations/2026-06-24-s14-reference-capable-generation/generation-log.md`
- `investigations/2026-06-24-s14-reference-capable-generation/s14-reference-test-plan.md`
## Diff Or Changed File References
- None
## Prior Decision References
- None
## Known Non Goals
- `Do not resume broad generation from s35 in the next session.`
- `Do not redo API/Garden image-generation research for normal Video Workbench work.`
- `Do not treat old text-only broad-run images as accepted finals.`
- `Do not replace source-file reading with this context index.`
## Open Questions For Reviewer Or Agent
- `How should project.md and execution-plan.md be updated to close stale pre-S14 open questions?`
- `What is the minimal per-shot production unit for the repaired workflow?`
- `How should the old broad-run candidates for s05, s14, s21, s25, and s33 be marked or replaced?`
## Blocking Errors
- None
## Machine Readable Manifest
- `review-file-manifest.json`

View File

@ -0,0 +1,284 @@
{
"review_id": "2026-06-24-on-the-road-workflow-continuation",
"context_profile": "handoff",
"project_root": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench",
"source_roots": [
"handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md",
"handoff/2026-06-24-on-the-road-style-reference-handoff.md",
"AGENTS.md",
"VIDEO_WORKBENCH.md",
"projects/2026-06-23-在路上/project.md",
"projects/2026-06-23-在路上/execution-plan.md",
"projects/2026-06-23-在路上/visual-system/visual-system.md",
"projects/2026-06-23-在路上/visual-system/characters",
"projects/2026-06-23-在路上/visual-system/style",
"projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md",
"projects/2026-06-23-在路上/slides/slides.md",
"projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md",
"investigations/2026-06-24-s14-reference-capable-generation"
],
"missing_source_roots": [],
"files_included": [
{
"path": "AGENTS.md",
"size_bytes": 3908,
"source_root": "AGENTS.md"
},
{
"path": "VIDEO_WORKBENCH.md",
"size_bytes": 13590,
"source_root": "VIDEO_WORKBENCH.md"
},
{
"path": "handoff/2026-06-24-on-the-road-style-reference-handoff.md",
"size_bytes": 8884,
"source_root": "handoff/2026-06-24-on-the-road-style-reference-handoff.md"
},
{
"path": "handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md",
"size_bytes": 10648,
"source_root": "handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/README.md",
"size_bytes": 2545,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/generation-log.md",
"size_bytes": 3817,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/lifecycle-guard-config.yaml",
"size_bytes": 1065,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-anchor-board-reference-prompt.md",
"size_bytes": 4372,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-side-crop-reference-prompt.md",
"size_bytes": 4331,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/reviews/comparison-and-user-review.md",
"size_bytes": 2632,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-anchor-board-reference-review.md",
"size_bytes": 3069,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-side-crop-reference-review.md",
"size_bytes": 2960,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md",
"size_bytes": 4163,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/s14-reference-test-plan.md",
"size_bytes": 4861,
"source_root": "investigations/2026-06-24-s14-reference-capable-generation"
},
{
"path": "projects/2026-06-23-在路上/execution-plan.md",
"size_bytes": 4361,
"source_root": "projects/2026-06-23-在路上/execution-plan.md"
},
{
"path": "projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md",
"size_bytes": 20628,
"source_root": "projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md"
},
{
"path": "projects/2026-06-23-在路上/project.md",
"size_bytes": 3774,
"source_root": "projects/2026-06-23-在路上/project.md"
},
{
"path": "projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md",
"size_bytes": 9926,
"source_root": "projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md"
},
{
"path": "projects/2026-06-23-在路上/slides/slides.md",
"size_bytes": 10429,
"source_root": "projects/2026-06-23-在路上/slides/slides.md"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-back-reference-crop-tight.png",
"size_bytes": 514654,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-front-reference-crop-tight.png",
"size_bytes": 550634,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-front-reference-crop.png",
"size_bytes": 580097,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-side-reference-crop-tight.png",
"size_bytes": 448440,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-walk-back-reference-crop-tight.png",
"size_bytes": 387226,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-walk-side-reference-crop-tight.png",
"size_bytes": 514280,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-identity-lock.md",
"size_bytes": 5147,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md",
"size_bytes": 3093,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-slice-side-v2-from-anchor.png",
"size_bytes": 1056370,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-slice-walk-back-v2-from-anchor.png",
"size_bytes": 828824,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-slice-walk-side-v2-from-anchor.png",
"size_bytes": 880680,
"source_root": "projects/2026-06-23-在路上/visual-system/characters"
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md",
"size_bytes": 18881,
"source_root": "projects/2026-06-23-在路上/visual-system/style"
},
{
"path": "projects/2026-06-23-在路上/visual-system/visual-system.md",
"size_bytes": 7343,
"source_root": "projects/2026-06-23-在路上/visual-system/visual-system.md"
}
],
"files_excluded": [
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/lifecycle-guard-output/lifecycle-status-guard-scan.json",
"reason": "exclude_pattern"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/lifecycle-guard-output/lifecycle-status-guard-scan.md",
"reason": "exclude_pattern"
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/outputs/s14-anchor-board-reference-v1.png",
"reason": "size_exceeds_limit",
"size_bytes": 3459163
},
{
"path": "investigations/2026-06-24-s14-reference-capable-generation/outputs/s14-side-crop-reference-v1.png",
"reason": "size_exceeds_limit",
"size_bytes": 3639880
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-codex-posture-test.png",
"reason": "size_exceeds_limit",
"size_bytes": 3834108
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-slice-back-v2-from-anchor.png",
"reason": "size_exceeds_limit",
"size_bytes": 1255933
},
{
"path": "projects/2026-06-23-在路上/visual-system/characters/character-slice-front-v2-from-anchor.png",
"reason": "size_exceeds_limit",
"size_bytes": 1328996
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-board-v1.png",
"reason": "size_exceeds_limit",
"size_bytes": 2762536
},
{
"path": "projects/2026-06-23-在路上/visual-system/style/style-anchor-c-repair-v1.png",
"reason": "size_exceeds_limit",
"size_bytes": 3874057
}
],
"important_reports": [
"investigations/2026-06-24-s14-reference-capable-generation/reviews/comparison-and-user-review.md",
"investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-anchor-board-reference-review.md",
"investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-side-crop-reference-review.md",
"investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md",
"projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md"
],
"test_or_validation_outputs": [
"investigations/2026-06-24-s14-reference-capable-generation/generation-log.md",
"investigations/2026-06-24-s14-reference-capable-generation/s14-reference-test-plan.md"
],
"diff_or_changed_file_references": [],
"prior_decision_references": [],
"known_non_goals": [
"Do not resume broad generation from s35 in the next session.",
"Do not redo API/Garden image-generation research for normal Video Workbench work.",
"Do not treat old text-only broad-run images as accepted finals.",
"Do not replace source-file reading with this context index."
],
"open_questions_for_reviewer_or_agent": [
"How should project.md and execution-plan.md be updated to close stale pre-S14 open questions?",
"What is the minimal per-shot production unit for the repaired workflow?",
"How should the old broad-run candidates for s05, s14, s21, s25, and s33 be marked or replaced?"
],
"metadata": {
"known_non_goals": [
"Do not resume broad generation from s35 in the next session.",
"Do not redo API/Garden image-generation research for normal Video Workbench work.",
"Do not treat old text-only broad-run images as accepted finals.",
"Do not replace source-file reading with this context index."
],
"open_questions_for_reviewer_or_agent": [
"How should project.md and execution-plan.md be updated to close stale pre-S14 open questions?",
"What is the minimal per-shot production unit for the repaired workflow?",
"How should the old broad-run candidates for s05, s14, s21, s25, and s33 be marked or replaced?"
],
"prior_decisions": [
"Reference-capable generation path is gpt-image-2 Advisor prompt/spec, then load the real image into context, then host image_gen.",
"Normal Video Workbench image generation should not use API/Garden unless the user changes the policy.",
"Near identity-heavy shots prefer matching crops; distant landscape-led shots prefer the anchor board or project-approved distant reference.",
"For On The Road, transparent crops derived from the accepted character anchor board are enough by default for consistency."
]
},
"blocking_errors": [],
"machine_readable_summary": {
"status": "PASS",
"source_roots_count": 13,
"missing_source_roots_count": 0,
"files_included_count": 32,
"files_excluded_count": 9,
"important_reports_count": 5,
"validation_outputs_count": 2,
"diff_references_count": 0,
"prior_decisions_count": 0,
"blocking_error_count": 0
}
}

View File

@ -0,0 +1,234 @@
# On The Road Workflow Continuation Handoff
## Status
- Date: 2026-06-24.
- Project: `projects/2026-06-23-在路上`.
- Current branch: `master`.
- Purpose: continuation handoff after style / character cleanup and the S14 reference-capable generation investigation.
- This document supersedes the open questions in `handoff/2026-06-24-on-the-road-style-reference-handoff.md` where those questions have since been answered.
Current context package:
```text
handoff/2026-06-24-on-the-road-workflow-continuation-context/review-context.md
handoff/2026-06-24-on-the-road-workflow-continuation-context/review-file-manifest.json
```
## Compression Self-Check
Because the working session was compressed, do not rely on chat continuity for exact state.
What is safely recoverable from files:
- current workspace rules in `AGENTS.md` and `VIDEO_WORKBENCH.md`;
- project control state in `project.md`, `execution-plan.md`, `visual-system/visual-system.md`, `slides/slides.md`, and `slides/broad-generation-self-audit-v1.md`;
- active character references in `visual-system/characters/character-reference-registry.md`;
- active style rules in `visual-system/style/style-prompt-master.md`;
- the S14 reference-capable generation investigation and generated test images under `investigations/2026-06-24-s14-reference-capable-generation/`;
- the user decision recorded in `investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md`.
What is not reliable after compression unless it was written to disk:
- exact intermediate chat wording around image judging;
- transient host image-generation internal IDs or default output locations;
- any unrecorded tool output from the compressed portion of the session;
- subjective visual impressions not captured in the review files or the user decision.
Practical consequence:
- Treat the files listed in this handoff and its context package as the continuation basis.
- Do not reconstruct workflow decisions from memory if a local file gives the current rule.
## Must Read First
Read these in order in a new session:
1. `AGENTS.md`
- UTF-8 rules.
- `gpt-image-2` Skill rule.
- current default host `image_gen` reference-by-visible-context path.
2. `VIDEO_WORKBENCH.md`
- project layout, `slides/sNN/sNN-vN-type.ext` naming, asset policy, and reference-capable image generation rule.
3. `projects/2026-06-23-在路上/project.md`
- project-local status and high-level state.
4. `projects/2026-06-23-在路上/execution-plan.md`
- still contains some pre-S14-investigation wording; read it as current project control plus stale open decisions that need cleanup.
5. `projects/2026-06-23-在路上/visual-system/visual-system.md`
- accepted visual system, A/B/C/D definitions, and style / character system.
6. `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
- active character references and selection rules.
7. `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md`
- active style modules, active style references, per-shot prompt requirements, and broad-generation repair rule.
8. `projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md`
- five-shot character-consistency test skeleton for `s05`, `s21`, `s14`, `s25`, `s33`.
9. `investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md`
- current reference-capable generation conclusion and user decision.
10. `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
- why broad generation is paused and what must be repaired.
## Current User Decisions
### Reference-Capable Generation
Use this path now and in future Video Workbench image generation:
1. Generate prompt/spec through `gpt-image-2` Skill Advisor workflow.
2. Load the real reference image into the conversation context before generation.
3. Generate with host `image_gen`, naming the loaded image role in the prompt, such as `Image 1: identity reference`.
Do not use API/Garden for normal Video Workbench image generation unless the user explicitly changes the policy.
Do not reopen "can references work" for ordinary work. Reopen only if the host image tool is unavailable, the image cannot be loaded into context, or the user changes the policy.
### Character Reference Selection
Current default:
| Shot need | Reference choice |
| --- | --- |
| Near / face / half-profile / expression / identity-heavy | matching crop first |
| Distant / landscape-led / aerial / low identity burden | full character anchor board or project-approved distant reference first |
| Medium action / back / walking / prop continuity | matching crop, transparent slice, or anchor board by visible direction |
| Future high-identity close-up-heavy project | consider generating higher-resolution crops through image-to-image from the accepted anchor board before production |
For `在路上`, most shots are landscape-led, distant, or aerial. The current crop set was cut from the accepted character anchor board and made transparent; this is enough by default for consistency rather than high-fidelity portrait likeness.
### Style Reference Selection
The common style phase has been cleaned and centralized into:
```text
projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md
```
Active style directory now contains:
```text
style-anchor-board-v1.png
style-anchor-c-repair-v1.png
style-prompt-master.md
```
Process files are under:
```text
projects/2026-06-23-在路上/archive/style/
```
Do not continue creating common style briefs, board specs, trial plans, HTML board sources, or contactsheets by default. Move to per-shot execution.
## Completed Since Previous Handoff
- Character directory cleaned.
- Active character references remain in `visual-system/characters/`.
- Historical/process files are under `archive/characters/`.
- `character-reference-registry.md` is the active reference registry.
- Style directory cleaned.
- `style-prompt-master.md` exists and is active.
- Active style assets are only the common style board and repaired C sample.
- Historical/process files are under `archive/style/`.
- Added character-consistency single-shot skeleton:
- `projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md`.
- Completed S14 reference-capable investigation:
- `investigations/2026-06-24-s14-reference-capable-generation/`.
- Generated outputs:
- `outputs/s14-anchor-board-reference-v1.png`
- `outputs/s14-side-crop-reference-v1.png`
- User decision recorded in `reviews/summary-and-rule-implications.md`.
- Promoted the reference-capable generation rule into:
- `AGENTS.md`
- `VIDEO_WORKBENCH.md`
## Important Stale Wording To Handle
Some older project files still predate the S14 investigation.
Examples:
- `execution-plan.md` still says the next decision is how to repair broad-generation reference handling.
- `visual-system/visual-system.md` still says the next action is deciding lightweight broad-production flow.
- `character-identity-lock.md` still says later scene prompts have not proven identity preservation.
Interpretation:
- These are not blockers for reference-capable feasibility anymore.
- They are cues for the next workflow-cleanup pass: update project control files so they point to the new reference-capable rule and the remaining per-shot workflow work.
## Current Working Tree Caveat
At the time this handoff was written, there are uncommitted changes from the reference-capable investigation/rule promotion work:
```text
AGENTS.md
VIDEO_WORKBENCH.md
investigations/README.md
investigations/2026-06-24-s14-reference-capable-generation/
handoff/2026-06-24-on-the-road-workflow-continuation-handoff.md
handoff/2026-06-24-on-the-road-workflow-continuation-context/
```
Do not assume these are committed until `git status --short` is checked.
## Next Recommended Work
The next session should optimize workflow, not restart image-reference research.
Recommended order:
1. Align stale control docs.
- Update `project.md`, `execution-plan.md`, and possibly `visual-system/visual-system.md` so they reflect:
- S14 reference-capable path is decided;
- common style phase is closed;
- remaining problem is per-shot production workflow and traceability.
2. Define the repaired per-shot production unit.
- Minimum likely files:
- `slides/sNN/sNN-vN-brief.md`
- `slides/sNN/sNN-vN-prompt.md`
- `slides/sNN/sNN-vN-image.png`
- `slides/sNN/sNN-vN-review.md` only when review is actually needed.
- Each prompt must include:
- style module;
- active style reference path(s);
- character reference path(s) or `none` with reason;
- reference roles;
- generation path note;
- output path.
3. Decide how to mark old broad-run images.
- `s05`, `s14`, `s21`, `s25`, and `s33` already have broad-run images, but those came from the flawed text-only broad run.
- Do not treat them as accepted finals.
- Decide whether to keep them as rejected candidates, replace them, or use them only as comparison examples.
4. Use the five-shot character-consistency skeleton as a workflow stress test if generation resumes.
- Recommended order from the intake file:
- `S-05 -> S-21 -> S-14 -> S-25 -> S-33`.
- Purpose now:
- validate per-shot traceability and reference selection under the decided path;
- not prove again that image references can work.
5. Only after the repaired workflow is tested, resume wider shot production.
## Do Not Do Next
- Do not continue broad generation from `s35`.
- Do not treat broad-run generated images as accepted finals.
- Do not redo API/Garden research for normal work.
- Do not ask whether reference images can work unless the host image tool or reference loading fails.
- Do not use archived character/style files as default references.
- Do not generate identity-critical shots from text-only character descriptions.
- Do not ask GPT V2 for final prompts; Codex owns final prompt construction through the `gpt-image-2` Skill workflow.
- Do not turn the project into a heavy governance/audit workspace; keep workflow records lightweight and execution-facing.
## Verification Artifacts
New context package:
```text
handoff/2026-06-24-on-the-road-workflow-continuation-context/review-context.md
handoff/2026-06-24-on-the-road-workflow-continuation-context/review-file-manifest.json
```
Lifecycle scan for this handoff:
```text
handoff/2026-06-24-on-the-road-workflow-continuation-context/lifecycle-guard-output/lifecycle-status-guard-scan.md
```

View File

@ -0,0 +1,239 @@
# R7 Governance Simplification Handoff
Date: 2026-06-25
Project:
```text
projects/2026-06-23-在路上
```
Task:
```text
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency
```
## Status
R6 completed the notification / wakeup test.
User intends to manually commit the current documents and then start a fresh session for R7.
Do not start R7 in the current session. Use this file as the new-session entrypoint.
## R6 Result Summary
Phase 1:
- Scope: `S-16` append-only repair.
- Child session: `session-09`, thread `019ef9bc-fe96-75b3-b902-5d5ef95feca3`.
- Parent callback target: `019ef9b5-cc39-7a42-91b1-f9b0852dc95e`.
- Result: child callback woke the parent without parent polling.
- Output: `s16-v3-image.png`.
- User accepted the image.
Phase 2 first attempt:
- Scope: `S-19/S-20/S-22/S-23`.
- Child session: `session-10`, thread `019ef9d0-4914-7ea0-8935-bfd9bfc1aad4`.
- Result: partial / paused.
- `S-19/s19-v2` completed and was accepted by user.
- `S-20` worker hung after attempting MiniMax MCP image understanding; the user disabled that MCP service.
- `s20-v2`, `s22-v2`, and `s23-v2` are incomplete evidence only. Do not backfill or complete those versions in place.
Phase 2 retry:
- Scope: `S-20/S-22/S-23/S-24`.
- Child session: `session-11`, thread `019ef9f8-8c34-77a3-82af-9a25beb2c723`.
- Result: callback-only completion gate passed; parent resumed without broad polling.
- Outputs accepted by user:
- `s20/s20-v3-image.png`
- `s22/s22-v3-image.png`
- `s23/s23-v3-image.png`
- `s24/s24-v2-image.png`
R6 mechanism conclusion:
- Callback-only parent wakeup works for a single-slide repair and a 4-shot package.
- Parent should not routinely poll child threads.
- Child session must write `child-session-handoff.md` before callback.
- Parent should read compact handoff first and inspect details only on warning / blocked / failed / explicit audit.
## Rule Changes Already Made
These files were updated before this handoff:
```text
AGENTS.md
VIDEO_WORKBENCH.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
```
The workflow default is now:
```text
parent dispatches -> parent stops routine waiting
child writes handoff -> child callbacks parent
parent wakes -> parent reads compact handoff
```
Polling is now only a fallback when callback tooling is unavailable or the user explicitly requests polling for a named run.
Important user decision:
- Do not add a global hard-stop rule banning MiniMax MCP or external visual tools.
- MiniMax MCP is currently disabled by user, but future tasks may explicitly authorize other external tools.
- Keep the existing boundary: external review / vision / image-understanding tools are not used by default; they require explicit task authorization.
## R7 Primary Goal
R7 should simplify governance for formal production.
The current mechanism works, but the test workflow carries too much governance:
- long task logs;
- repeated audit summaries;
- verbose handoffs;
- detailed worker evidence lists;
- repeated parent-side post-processing;
- token-heavy histories that do not directly produce images.
R7 should define and test a production-light profile that keeps enough traceability to recover from real failures, but stops spending routine tokens on test-level audit.
## R7 Design Target
Use two modes:
```text
test / investigation mode
production-light mode
```
Test / investigation mode keeps the current heavier evidence style when debugging workflow mechanics.
Production-light mode should be the default for normal image production after R7 if the trial passes.
Recommended production-light record set:
- `task-plan.md`: one compact active-scope block only; no long historical replay.
- `task-log.md`: one line per dispatched package and one line per callback result; no timeline expansion unless a problem occurs.
- `slides/slides.md`: authoritative slide status table.
- `child-session-plan.md`: compact package plan with assigned slides, callback target, write policy, and stop conditions.
- `child-session-handoff.md`: compact parent surface with status, completion gate, versions, image paths, and decisions needed.
- Per slide: keep brief, prompt, image, and return files.
Recommended production-light omissions unless a problem occurs:
- no per-package long narrative timeline;
- no parent-side re-verification of prompt / return / ledger when handoff is clean;
- no full file inventory in parent records;
- no review files when review is disabled;
- no duplicate worker audit unless handoff reports a warning;
- no broad status heartbeat text after dispatch;
- no copying large handoff content into project-level files.
Evidence that should remain mandatory:
- append-only version resolution;
- overwrite disabled;
- one owning worker per slide/version;
- child-owned brief and packet before worker launch;
- callback target recorded;
- handoff exists before callback;
- completion gate status;
- image path for every completed slide;
- review present or absent according to task mode.
## Suggested R7 Trial Shape
Before dispatch, align with the user on two things:
1. Whether R7 should first update workflow docs for production-light mode, or run one small package and then update docs from evidence.
2. Which slide scope to use.
If the user wants a concrete default scope, propose a small continuation package after the accepted R6 range:
```text
S-26/S-27/S-28
```
Reason:
- `S-25` is already accepted.
- `S-26/S-27/S-28` are the next contiguous post-R6 shots in the table.
- Three slides are enough to test reduced governance without using a large package as the first production-light trial.
If the user wants to stress the 4-shot callback package again, propose:
```text
S-26/S-27/S-28/S-29
```
Do not choose the scope silently. R7 is about workflow simplification, so the scope should be explicitly recorded before dispatch.
## Read First In R7
Read these files first:
```text
AGENTS.md
VIDEO_WORKBENCH.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/session-11/child-session-handoff.md
```
Avoid re-reading older session directories unless investigating a specific defect.
## Files With Current State
Current accepted outputs and workflow conclusions are recorded in:
```text
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-plan.md
projects/2026-06-23-在路上/tasks/2026-06-24-character-consistency/task-log.md
```
Current callback-only rule source:
```text
AGENTS.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
VIDEO_WORKBENCH.md
```
## R7 Non-Goals
- Do not re-test whether callback-only wakeup works unless the new session sees a concrete tool failure.
- Do not reinstate routine polling as the default.
- Do not turn production-light mode into a new audit framework.
- Do not delete historical evidence from R4/R5/R6.
- Do not backfill incomplete `s20-v2`, `s22-v2`, or `s23-v2`.
- Do not add a global hard ban on MiniMax MCP or future external visual tools.
- Do not run CCPE.
## First Message Guidance For New Session
The new session should start by saying:
```text
I have read the R7 handoff. My understanding: R6 proved callback-only wakeup; R7 should reduce routine governance tokens for formal production while keeping append-only versioning, completion gate, and compact callback handoff. I will not poll child threads by default, and I will not add a global hard ban on external visual tools. First I will confirm whether to update workflow docs before the trial and confirm the R7 slide scope.
```
Then ask the user for the R7 choice:
```text
Do you want R7 to first revise the docs for production-light mode, or run one small production-light package and update the docs from the result?
```

View File

@ -0,0 +1,251 @@
# On The Road Formal Production Handoff
Date: 2026-06-25
Project:
```text
projects/2026-06-23-在路上
```
Purpose:
Use this as the entrypoint for the next clean main session after R7. The project has completed formal production-light shot-image generation for the current 51-shot table.
## Current Status
The workflow test line is closed for normal production, and the planned shot-image production pass is complete.
`project.md` now records:
```text
Workflow phase: production-light
Lifecycle phase: assembly-closeout
```
Accepted production route:
- Main session talks with the user and defines scope.
- Main session creates a clean named child session, with UI title beginning `子会话:...`.
- Child session directly writes each slide's brief and prompt, then generates images sequentially.
- Child session updates `slides/slides.md`, completes narrow required checks, writes a compact `child-session-handoff.md`, and callbacks the parent as its final action.
- After a successful callback, the child session must not write or verify additional project files.
- No Agent/SubAgent by default.
- No review file by default.
- No slide-agent packet or return receipt by default.
- No routine final completeness audit.
- Keep write-before version scanning, append-only versions, and overwrite disallowed.
R7 evidence:
- `session-12`: `S-26/S-27/S-28`, Agent-backed production-light, accepted by user, 25m48s / 134K tokens.
- `session-13`: `S-29/S-30/S-31`, direct child session without Agent/SubAgent, accepted by user, 10m32s / 114K tokens.
`session-13` is the current formal production model.
Capacity validation after R7:
- `session-01` under `tasks/2026-06-25-production-capacity-validation`: `S-32/S-34/S-35/S-36/S-37`, direct child session without Agent/SubAgent, accepted by user.
- User observed callback at about 152K tokens / 58% context and final usage after post-callback document/check work at about 164K tokens / 63% context.
- Mechanism warning: this validation exposed a callback-order defect because the child wrote/checked after callback. Future child prompts must state that callback is the final action.
- `session-01` under `tasks/2026-06-25-8slide-compression-validation`: `S-38/S-39/S-40/S-41/S-42/S-43/S-44/S-45`, direct child session without Agent/SubAgent, accepted into production-pass by production-stage default.
- User observed final package usage at 174K tokens / 67% context and 38m37s elapsed.
- The callback-final contract was verified: no child project writes or checks were observed after the callback/final child response.
- Ordinary production-light package size is now up to 8 slides.
- `session-01` under `tasks/2026-06-25-final-production-s48-s50`: `S-48/S-49/S-50`, direct child session without Agent/SubAgent, completed with `problems: none` and `needs_user: none`.
- Parent verification found expected brief/prompt/image files present, exact review files absent, `slides/slides.md` updated, and no post-callback child writes.
## New Session Load Order
For a cleanup / discussion-only new session, load in this order:
```text
AGENTS.md
handoff/2026-06-25-on-the-road-formal-production-handoff.md
projects/2026-06-23-在路上/project.md
projects/2026-06-23-在路上/execution-plan.md
projects/2026-06-23-在路上/slides/slides.md
```
For a session that may dispatch production image generation, then load:
```text
VIDEO_WORKBENCH.md
docs/workflows/project-lifecycle.md
docs/workflows/slide-task-orchestration.md
docs/workflows/slide-task-templates.md
projects/2026-06-23-在路上/visual-system/visual-system.md
projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md
projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md
```
For the actual assigned slide scope, load only the relevant source rows and files:
```text
projects/2026-06-23-在路上/intake/阶段五-镜头清单骨架.md
projects/2026-06-23-在路上/intake/阶段五-核心单镜.md # only for S-10/S-46/S-51 or if referenced
projects/2026-06-23-在路上/slides/sNN/
```
Do not read old session directories, old handoffs, or the external discussion record unless investigating a specific inconsistency. This handoff supersedes the R7 governance-simplification handoff for normal production.
## If The User Directly Says "生图"
First classify the request:
1. Clear slide scope: proceed with that named scope.
2. Clear natural-language scope: map it to slide IDs using `slides/slides.md`, then confirm only if mapping is ambiguous.
3. No scope, just "继续生图" or equivalent: use the "Default Next Scope" section below.
4. Repair / local problem / quality concern: ask whether to use `production-light` retry or `test/audit` override.
Do not start generation without an explicit slide scope unless the user clearly authorizes "continue from the current next production scope".
## Default Next Scope
Accepted / production-pass now includes the current 51-shot table. Key late-production coverage:
```text
S-26/S-27/S-28/S-29/S-30/S-31/S-32/S-33/S-34/S-35/S-36/S-37/S-38/S-39/S-40/S-41/S-42/S-43/S-44/S-45/S-46/S-47/S-48/S-49/S-50/S-51
```
The remaining not-started story-order items are:
```text
none
```
Reason:
- `S-32/s32-v2`, `S-34/s34-v2`, `S-35/s35-v1`, `S-36/s36-v1`, and `S-37/s37-v1` were accepted by user in the capacity validation package.
- `S-33` is already accepted as `s33-v2`; skip by default.
- `S-38` through `S-45` are accepted into the production pass after the 8-slide compression validation.
- `S-46`, `S-47`, and `S-51` are already accepted anchor/trial outputs.
- `S-48` through `S-50` were completed in the final production direct-child package.
If the user says "直接继续正式生产" with no other scope, do not dispatch a new image-production package. Report that the current shot-image table is complete and ask whether to proceed to assembly / export / closeout or to name a slide for append-only repair.
```text
no remaining default production scope
```
For append-only repair/retry, the child session must still scan each slide folder before writing; any expected versions are not authority.
## Scope Rules
Use `slides/slides.md` as the source of truth for production scope.
Closed by default:
- status `accepted`;
- status `production-pass`;
- rows explicitly recorded as user accepted in current project/task records.
Open by default:
- status `not started`;
- status `generated` without user acceptance;
- broad-run candidate only;
- incomplete / paused evidence;
- rejected historical evidence;
- repair requested by user.
Important cleanup note:
Some older rows still use wording such as `generated / session-07 complete` even where project/task records say the user accepted the images. The next cleanup pass should normalize these statuses before large-scale batching. Until then, for any ambiguous row, prefer the latest explicit user-acceptance record in `project.md`, `execution-plan.md`, `task-log.md`, and `slides.md`.
Default child-session package size:
```text
maximum 8 ordinary production slides
```
Use 1-3 slides for identity-heavy, repair-heavy, core-risk, or context-expensive scopes. Split larger scopes into multiple child sessions unless the user explicitly authorizes a larger package.
## Production Dispatch Defaults
When dispatching a production-light package, create one clean child session.
Title format:
```text
子会话:在路上 S48-S50 production-light
```
Use a concise parent instruction with these fields:
```text
Project: projects/2026-06-23-在路上
Line: production-light
Topology: direct child session; no Agent/SubAgent
Worker profile: video-slide-production
Running mode: prompt and generate
Review mode: none
Scope: <S-NN list>
Callback target: <current parent thread id>
Write policy: append-only; overwrite allowed: no
Required source of truth: project.md, execution-plan.md, slides/slides.md, visual-system/
Output: brief, prompt, image, slides.md update, compact child-session-handoff.md
Callback payload: status, topology, resolved versions, handoff path, image paths, problems, needs_user
Callback order: callback is the child session's final action after all allowed writes, narrow checks, and handoff work; do not write or verify project files after a successful callback
```
The child must:
- scan existing `slides/sNN/sNN-v*-*` files before choosing each version;
- stop on artifact collision instead of overwriting;
- create no `sNN-vN-review.md` unless the parent explicitly changes review mode;
- create no packet/return files unless the parent explicitly switches to test/audit, repair, or Agent-backed mode;
- use `gpt-image-2` Advisor / host-native workflow;
- load real visible-context image references before generation when identity or reference control matters;
- keep prompts compact and generation-oriented;
- update `slides/slides.md` for completed outputs;
- write compact handoff before callback;
- send callback as the final child action and perform no project writes/checks afterward.
The parent must:
- not poll the child thread routinely;
- not audit prompt/image/ledger details after a clean callback;
- inspect details only on `blocked`, `failed`, `warning`, collision, explicit user audit, or ambiguous scope/status.
## Test / Audit Override
Use `test/audit` only when:
- the user asks to investigate a workflow problem;
- a generated image fails and needs diagnosis rather than a simple append-only retry;
- a new core visual rule needs proving;
- external review / local review / Agent isolation is explicitly requested;
- duplicate worker, collision, missing reference, or tool failure occurs.
In `test/audit`, Agent/SubAgent, packet/return files, local review, and fuller completion gates are allowed. They are not the formal production default.
## Current Known Boundaries
- Do not invoke CCPE.
- Do not ask GPT V2 for final prompts.
- Do not call MiniMax MCP or external vision/review services unless explicitly authorized for the task.
- Do not regenerate accepted slides by default.
- Do not reuse broad-run candidate images as accepted finals unless the user explicitly accepts them.
- Do not backfill old broad-run prompt/brief files as if they were original generation inputs.
- Do not overwrite existing artifacts.
## Cleanup Topics For The Next Session
Likely useful cleanup / discussion items before or during production:
- Normalize old `slides.md` statuses where user acceptance is recorded elsewhere but row status still says `generated`.
- Decide whether broad-run `s32-v1` and `s34-v1` should be accepted as candidates or superseded by formal append-only production versions.
- Consider whether `S-15/S-17/S-18` are merely generated historical evidence or should be reviewed/accepted/retried before final assembly.
- Keep R7 production-light rules; do not reopen the Agent/default-governance debate unless a new failure appears.
## Stop Conditions
Stop and ask the user if:
- the requested slide scope cannot be mapped cleanly;
- the next scope would include an already accepted slide;
- a target output path already exists;
- required character/style references cannot be loaded;
- the user request implies review/audit but does not say which line to use;
- the child callback reports `blocked`, `failed`, or `warning`.

View File

@ -1,13 +0,0 @@
# Active Episodes
No active standalone episodes yet.
Record:
- episode id
- temporary title
- source-map path
- current stage
- duration target
- next action

View File

@ -1,13 +0,0 @@
# Active Series
No active series projects yet.
Record:
- series id
- temporary title
- source model / essay
- episode count
- current episode
- next action

View File

@ -1,13 +0,0 @@
# Completed Videos
No completed videos yet.
Record:
- episode id
- final title
- source article/model
- final script path
- asset paths
- publish status

View File

@ -1,13 +0,0 @@
# Source Article Map
This index maps video outputs back to Knowledge Vault sources.
Record:
- video or episode id
- source essay path
- source model path
- source notes or research
- extracted point
- resulting package path

View File

@ -0,0 +1,414 @@
# 01-分工与目录改造草案
```yaml
status: draft
date: 2026-06-23
scope:
- video-workbench 本地执行体系
- GPT「强哥的策划导演」协作边界
- gpt-image-2 Advisor 模式的提示词职责
premise:
- v2 提示词质量调研结论已被接受
- 当前只确认提示词质量,不确认最终出图质量
non_goals:
- 不直接修改 GPT Builder 或 GPT 知识库
- 不直接新增 video-workbench/docs 下的稳定文档
- 不验证生图效果、图生图效果或视频生成效果
- 不迁移既有项目目录
```
## 一、前提结论
这次改造的起点不是“人物定妆照”本身,而是一个更上层的职责判断:
> GPT 负责方向、结构、教学或叙事意图Codex 在本地负责把视觉资产需求转成可执行、可追踪、可复用的最终图像提示词。
v2 调研已经支持这个判断。尤其在高频场景里,`gpt-image-2` Advisor 模式比 Codex 直接写提示词更稳定:
- 科普视频 / 分镜类内容Advisor 更擅长把抽象概念拆成可视化结构、画面层级、动态感、非文字依赖表达。
- 培训 AI / PPT 类内容Advisor 更擅长区分页面文字、讲解逻辑、视觉资产、标题安全区和留白。
- 人物造型 / 定妆照Advisor 仍有价值,但在当前使用场景中权重最低,只作为条件能力沉淀。
因此后续改造不应围绕“GPT 如何写更好的生图 Prompt”展开而应围绕“GPT 如何把视觉任务交接给 Codex由 Codex 本地生成最终 Prompt”展开。
## 二、新的三方分工
| 角色 | 主要职责 | 不再默认承担 |
| --- | --- | --- |
| 强哥 | 提供目标、素材、判断标准;决定采用哪版方向、哪版提示词、哪版资产 | 不需要手工维护每个视觉资产的最终 Prompt 版本 |
| GPT「强哥的策划导演」 | 做选题理解、结构规划、分镜 / 页面设计、教学意图、视觉方向、导演卡、验收标准、Codex 交接包 | 不默认输出最终生图 Prompt / 图生图 Prompt / 镜头 Prompt |
| Codex / video-workbench | 本地建档、拆解任务、调用 `gpt-image-2` Advisor 模式生成最终提示词、保存提示词和资产版本、组织复盘 | 不替代强哥做方向决策;不把调研结论直接当稳定规范 |
| `gpt-image-2` Skill | 作为 Codex 本地提示词工程能力,提供 Advisor 模式和结构化图像提示词方法 | 不是 GPT 的知识库文件,也不是 GPT 必须直接掌握的完整执行流程 |
一句话边界:
> GPT 输出“视觉任务说明书”Codex 输出“可执行图像提示词”;生成结果和版本记录留在 video-workbench 项目目录。
## 三、媒介输出边界
### 1. 科普视频 / 视频分镜
这是当前最高权重场景。
GPT 应输出:
- 主题理解和核心解释路径
- 每页 / 每镜的讲解目标
- 画面构图方向
- 视觉隐喻或演示机制
- 页面文字建议
- 可交给 Codex 的导演卡
- 该页 / 该镜的验收标准
Codex 应输出:
- `image-prompt-vN.md`
- 必要时的 `image-edit-prompt-vN.md`
- 生成或外部生成后的图片资产
- 对照验收标准的复盘记录
### 2. 培训 AI / PPT 类内容
这是第二高权重场景,且比人物类更常见。
GPT 应重点处理:
- 教学目标
- 页面信息层级
- 页面文字
- 讲解顺序
- 视觉资产用途
- 适合 PPT 的留白和标题区
Codex 应重点处理:
- 视觉资产提示词
- 图像里不承载长段文字的约束
- 页面文字与图片文字的边界
- 素材版本和复用记录
原则:
> PPT / 网页 / 视频页面上的文字属于页面层,不应默认塞进图片提示词里。图片提示词主要负责视觉资产,而不是负责排版整页 PPT。
### 3. 人物造型 / 定妆照
这是条件场景,不是本次体系的中心。
只在项目中出现稳定人物、主持人、角色、连续剧情或需要跨镜头形象一致时启用。
GPT 可输出:
- 人物身份定位
- 角色气质
- 服装 / 发型 / 妆造方向
- 表情和姿态参考
- 连续使用注意点
Codex 应输出并保存:
- 定妆照提示词
- 生成后的定妆图
- 人物一致性参考说明
- 后续镜头调用该人物时的引用记录
## 四、目录改造草案
### 1. `investigations/`
用途:调研、验证、草案和过渡文件。
本文件目前就放在 `investigations/` 下,因为它还不是稳定工作规范。只有强哥确认后,才把其中的稳定部分迁移到 `docs/`
建议规则:
- 调研报告、实验记录、对比样例、草案放这里。
- 不把这里的文件默认当作项目运行规范。
- 被接受的结论要迁移到 `docs/` 或项目模板后才算稳定知识。
### 2. `docs/`
用途video-workbench 的稳定本地知识库。
本次草案通过后,建议新增以下文档:
```text
docs/image-prompt-advisor-workflow.md
docs/visual-asset-prompt-rubric.md
docs/page-text-vs-image-prompt-boundary.md
docs/makeup-still-directory-policy.md
```
四个文档的优先级:
1. `image-prompt-advisor-workflow.md`
- 规定 Codex 如何从 GPT 导演卡进入 Advisor 模式。
- 规定输出哪些提示词文件、如何命名、如何复盘。
2. `visual-asset-prompt-rubric.md`
- 固化 v2 调研使用的提示词质量维度。
- 用于判断提示词是否足够具体、可执行、可生成。
3. `page-text-vs-image-prompt-boundary.md`
- 规定页面文字、PPT 文字、视频字幕、图片内文字的边界。
- 避免把可编辑文字错误地塞进图片生成任务。
4. `makeup-still-directory-policy.md`
- 规定什么时候需要 `makeup-still/`
- 规定人物提示词、定妆图、人物一致性说明如何保存。
### 3. `projects/<project-id>/intake/`
用途:保存已接受的 GPT 上游输出和项目输入。
建议保存:
```text
projects/<project-id>/intake/source.md
projects/<project-id>/intake/gpt-direction.md
projects/<project-id>/intake/gpt-outline.md
projects/<project-id>/intake/gpt-execution-package.md
projects/<project-id>/intake/references.md
```
其中 `gpt-execution-package.md` 可以包含 GPT 输出的导演卡集合、页面目标、视觉方向、验收标准和 Codex 交接说明。
### 4. `projects/<project-id>/slides/sNN/`
用途:保存单页 / 单镜头的执行资产。
当前 workbench 已经使用 `slides/sNN/` 作为单位目录,因此本次不另起 `shots/` 体系。即使是视频分镜,也先沿用 `slides/sNN/` 作为“一屏 / 一镜 / 一页”的统一执行单元。
建议结构:
```text
projects/<project-id>/slides/s01/
director-card.md
visual-brief.md
image-prompt-v1.md
image-prompt-v2.md
image-v1.png
image-v2.png
review-notes.md
voiceover.md
metadata.json
```
文件边界:
- `director-card.md`:来自 GPT 或由 Codex 整理的导演卡,描述该页 / 该镜要达成什么。
- `visual-brief.md`:面向视觉资产的需求说明,可由 GPT 输出,也可由 Codex 从上游材料压缩而来。
- `image-prompt-vN.md`Codex 调用 Advisor 模式后的最终图像提示词。
- `image-vN.png`:对应提示词生成或外部平台生成后的图片。
- `review-notes.md`:强哥 / Codex 对该页资产的验收和修改记录。
- `metadata.json`:可选,用于记录模型、平台、版本、来源路径和引用关系。
### 5. `projects/<project-id>/makeup-still/`
用途:人物定妆、角色形象和跨镜头人物一致性。
这是条件目录,不是所有项目都需要。
启用条件:
- 项目有固定主持人、角色或拟人 IP。
- 多张图片 / 多个镜头需要保持同一人物形象。
- 定妆图会被后续图生图、视频生成、封面或分镜反复引用。
建议结构:
```text
projects/<project-id>/makeup-still/
identity-brief.md
identity-prompt-v1.md
identity-ref-v1.png
wardrobe-prompt-v1.md
wardrobe-ref-v1.png
pose-ref-notes.md
consistency-notes.md
acceptance-notes.md
```
规则:
- 定妆提示词由 Codex 生成。
- 定妆图可以由 Codex 生成,也可以由强哥在外部平台生成后放入该目录。
- 无论图片从哪里来,只要成为项目人物参考,就应进入 `makeup-still/`
- 不出现人物或人物不需要连续一致时,不创建该目录。
### 6. `garden-gpt-image-2/`
用途:工具级 prompt / workflow trace不是项目资产的最终归档地。
建议规则:
- Skill 调试、通用样例、工具行为记录可以放这里。
- 某个项目真正采用的提示词和图片,应复制或记录到对应 `projects/<project-id>/slides/sNN/``makeup-still/`
- 不让项目资产只停留在 `garden-gpt-image-2/`
### 7. `tmp/`
用途:短期临时文件。
建议规则:
- 临时测试可以放这里。
- 调研证据、可复用草案、已接受结论不放这里。
- 能被后续复盘引用的内容,应放入 `investigations/`
### 8. `requirements/ccpe/``requirements/skills-vault/`
用途:能力缺口外部请求。
建议规则:
- 如果是 GPT / CCRA 知识库改造需求,先形成改动清单或审阅包,不在 video-workbench 内伪装成已完成改造。
- 如果是可复用 Skill、脚本、校验器、打包器能力写入 `requirements/skills-vault/`
- 如果涉及 CCPE 正式参与者、审查协议或跨 Agent 调度,写入 `requirements/ccpe/`
## 五、GPT 知识库 / CCRA 改动清单
这部分只记录“需要改什么”,不在本文件中执行。
### 1. `强哥的策划导演.md`
需要把默认输出从“最终 Prompt”降级为“导演层交接物”。
建议调整:
- 将“画面 Prompt / 镜头 Prompt / 生图 Prompt / 图生图 Prompt”改为条件输出。
- 默认输出改为:
- 视觉资产意图
- 页面 / 分镜导演卡
- 视觉 brief
- 可交给 Codex 的执行说明
- 验收标准
- 增加边界说明:最终图像提示词由 Codex 结合 `gpt-image-2` Advisor 模式在本地生成。
### 2. `00_CORE_附录B_内容类型识别与分流.md`
需要把科普视频、培训 PPT、MV / 人物类任务分流到不同视觉交接级别。
建议新增或调整字段:
```text
prompt_owner: codex
gpt_output_level: director_card | visual_brief | execution_package
advisor_mode_required: true | false
```
### 3. `00_CORE_附录C_视频_MV_短剧_深度执行模式.md`
需要拆分“导演层”和“最终提示词层”。
建议调整:
- GPT 输出镜头意图、构图、节奏、视觉隐喻、验收标准。
- 不默认输出最终 image prompt。
- 人物连续性场景增加 `makeup-still/` 交接提醒。
### 4. `00_CORE_附录E_Codex_交接与本地执行.md`
这是最需要调整的核心文件之一。
建议新增:
- Codex 接收 GPT 导演卡后,进入 `gpt-image-2` Advisor 模式。
- Codex 在项目目录保存 `image-prompt-vN.md`
- Codex 保存生成图片、外部图片来源和验收记录。
- Codex 将人物定妆资产保存到 `makeup-still/`
### 5. `21_SYSTEM_多工具协同与流程编排.md`
需要把“GPT 直接产 Prompt”改成“GPT 编排任务Codex 负责本地提示词执行”。
建议强调:
- GPT 是策划导演,不是本地资产管理员。
- Codex 是执行、归档、版本管理和提示词工程落地者。
- Advisor 模式是 Codex 的本地能力,不是 GPT 必须内置的完整流程。
### 6. `30_CASE_典型视频分镜案例.md`
保留作为科普视频高频样例,但需要改标注。
建议:
- 将旧版直接 Prompt 示例标为 legacy baseline 或“提示词颗粒度参考”。
- 新增一版“GPT 应输出的导演卡 / visual brief”。
- 新增一版“Codex 应生成的最终 image prompt”作为本地执行示例。
### 7. `31_CASE_典型培训AI_PPT案例.md`
保留并提高权重,因为它更接近实际高频使用。
建议:
- 明确页面文字由 PPT / 网页层承载。
- 图片提示词只负责视觉资产。
- GPT 输出教学目标、页面结构、视觉资产用途。
- Codex 输出视觉资产提示词和版本记录。
### 8. `10_STYLE_强哥偏好与审美取向.md`
可暂缓,只在需要统一美学偏好时再改。
建议:
- 不把风格偏好扩写成复杂 prompt 规范。
- 只保留可影响导演卡和 visual brief 的偏好描述。
### 9. `90_ARCHIVE/`
不作为本轮改造对象。
建议:
- 只读参考。
- 不上传为 GPT 当前知识。
- 不把 archive 里的旧 prompt 体系当作当前职责边界。
## 六、video-workbench 稳定文档候选
本草案通过后,建议在 `docs/` 下新增四个稳定文档。
| 文档 | 解决的问题 | 来源 |
| --- | --- | --- |
| `docs/image-prompt-advisor-workflow.md` | Codex 如何从 GPT 导演卡生成最终图像提示词 | 本草案 + v2 调研 |
| `docs/visual-asset-prompt-rubric.md` | 如何评价提示词质量 | v2 调研评分维度 |
| `docs/page-text-vs-image-prompt-boundary.md` | 页面文字和图片提示词的职责边界 | 培训 AI / PPT 高频场景 |
| `docs/makeup-still-directory-policy.md` | 什么时候创建人物定妆目录 | 条件人物场景 |
这些文档应在强哥确认本草案后再创建,避免把草案过早固化。
## 七、建议执行顺序
1. 强哥审阅并修订本草案。
2. Codex 将被接受的部分迁移为 `docs/` 下的稳定文档。
3. Codex 准备 GPT / CCRA 知识库改动清单或补丁包。
4. 用一个真实的科普视频或培训 AI PPT 项目做单页 / 单镜试运行。
5. 根据试运行结果,再决定是否需要模板、脚本或校验器。
## 八、验收标准
本草案被接受时,应满足:
- 高频权重正确:科普视频 > 培训 AI / PPT > 人物造型。
- GPT 不再默认承担最终图像提示词生成。
- Codex 明确承担本地图像提示词工程和文件归档。
- `makeup-still/` 是条件目录,不是所有项目的默认目录。
- `investigations/``docs/` 的边界清楚。
- 没有把提示词质量结论夸大为最终图片质量结论。
- 没有把 GPT 知识库改造伪装成已经执行完成。
## 九、暂不做
本轮不做:
- 不直接生图。
- 不验证最终图片质量。
- 不改 GPT Builder。
- 不改 knowledge-vault 中的 GPT 知识库文件。
- 不新增稳定 `docs/` 文档。
- 不迁移现有项目目录。
- 不引入自动化脚本。

View File

@ -0,0 +1,597 @@
# 01-分工与目录改造草案2.0
```yaml
status: draft
date: 2026-06-23
scope:
- video-workbench 本地执行流程
- GPT「强哥的策划导演 V2」阶段0-5 Markdown 接收方式
- Codex 阶段6以后执行、试错、提示词和资产落盘规则
basis:
- GPT V2 已完成改造
- GPT 不再输出最终图像 Prompt
- GPT 不再输出 Codex JSON 或执行包
- Codex 从 GPT V2 Markdown 策划稿中自行生成本地执行计划
non_goals:
- 不修改 GPT V2 知识库
- 不恢复旧版 Codex JSON 流程
- 不要求一次性生成全套 Prompt
- 不设置默认导出或剪辑流程
```
## 一、总体边界
GPT「强哥的策划导演 V2」的默认终点是阶段5
```text
阶段0任务路由
阶段1原始势能扫描
阶段2降维方向提案
阶段3媒介总纲设计
阶段4通用表达与视觉系统设计
阶段5分镜 / 页面 / 内容骨架
```
video-workbench 的默认起点是阶段6
```text
阶段6本地执行启动
```
Codex 不再向 GPT 索要:
- 最终图像 Prompt
- Negative Prompt
- Codex JSON
- video-workbench task list
- output_path
- 图像生成参数;
- 批量出图任务单。
Codex 接收的是 GPT V2 的阶段0-5 Markdown 策划结果并在本地完成执行计划、视觉系统物化、提示词生成、资产生成、review、失败归因和迭代。
## 二、角色分工
| 角色 | 负责 | 不负责 |
| --- | --- | --- |
| 强哥 | 建立或授权具体项目;确认 GPT 策划结束;决定是否进入 Codex 执行;审阅关键成果 | 不维护每个资产的提示词版本和迭代记录 |
| GPT V2 | 阶段0-5策划总纲通用表达与视觉系统页面 / 分镜 / 内容骨架 | 不输出最终 Prompt不输出 Codex JSON不规定本地目录和执行路径 |
| Codex / video-workbench | 阶段6以后本地执行解析 GPT Markdown生成 `execution-plan.md`;物化 `visual-system/`;生成和迭代单元资产 | 不把 GPT 策划稿当成执行命令;不等待 GPT 提供 JSON |
| `gpt-image-2` Advisor | 为 Codex 提供图像提示词工程支持 | 不替代项目级执行计划和本地 review |
一句话边界:
> GPT V2 给“策划骨架和公共系统”Codex 把它变成“本地执行计划、视觉系统、提示词、资产和迭代记录”。
## 三、本地流程2.0
本地流程压缩为五个阶段。
### 1. Intake Locked
触发条件:
- 具体项目已经建立或由强哥授权建立;
- `projects/<project-id>/intake/` 已放入 GPT V2 给出的全部 Markdown 文件;
- 强哥明确表示 GPT 策划工作结束,可以进入 Codex 执行。
Codex 在这一阶段做:
- 确认 `intake/` 中有哪些 GPT V2 文件和用户素材;
- 创建或更新 `project.md`
- 补齐本地执行需要的目录和索引文件;
- 不把 `intake/` 中的 GPT Markdown 改写成另一套完整内容;
- 不回头要求 GPT 提供 Prompt、JSON 或 task list。
建议项目起始结构:
```text
projects/<project-id>/
project.md
intake/
execution-plan.md
visual-system/
visual-system.md
slides/
slides.md
```
如果项目不是视觉类任务,可以不创建 `visual-system/``slides/`
### 2. Build Local Execution Plan
`parse stage outputs` 不作为单独文档阶段。Codex 可以在讨论和分析中解析 GPT V2 Markdown但最终判断要汇总进项目级 `execution-plan.md`
视觉类项目默认必须有:
```text
projects/<project-id>/execution-plan.md
```
`execution-plan.md` 不是旧 GPT JSON 的替代品,也不是一次性批量任务清单。它是本地执行的活文档,记录当前项目如何试、怎么分批、跑到哪一轮、下一步做什么。
建议内容:
```md
# Execution Plan
项目索引:见 `project.md`
## 1. Execution Scope
- medium_branch:
- current_phase:
- current_focus:
- next_decision:
## 2. Visual-System Materialization Plan
- assets_to_fix:
- first_round_targets:
- acceptance_criteria:
- open_questions:
## 3. Unit Iteration Plan
| batch | units | purpose | entry_condition | status | decision |
## 4. Current Round
- round:
- units_or_assets:
- prompts_to_generate:
- images_to_generate:
- review_focus:
- next_action:
## 5. Decision Log
| date | decision | reason | affected files |
```
使用规则:
- 每次进入新一轮视觉系统试跑或页面 / 镜头试跑前,先更新 `execution-plan.md`
- 它记录“执行策略、批次、轮次、当前决策”。
- 它可以包含进度概览,但不替代 `slides/slides.md` 的单元执行明细。
- 它可以先小批次推进,不要求全项目 Prompt 一次性生成完。
- 项目 ID、媒介类型、`intake/` 文件索引和关键路径由 `project.md` 维护,不在 `execution-plan.md` 中重复展开。
### 3. Materialize Visual System
这是阶段6以后最关键的本地执行阶段。
统一使用:
```text
projects/<project-id>/visual-system/
```
不再使用独立的:
```text
projects/<project-id>/makeup-still/
```
人物定妆、角色一致性、场景参考、PPT 背景、页面模板、图示风格、公共提示词、图片母版和参考资产,都归入 `visual-system/`
建议结构:
```text
projects/<project-id>/visual-system/
visual-system.md
refs/
iterations/
```
可按项目需要增加子目录:
```text
visual-system/
characters/
scenes/
templates/
diagrams/
backgrounds/
refs/
iterations/
```
文件边界:
- `visual-system.md`:三合一记录公共视觉系统的当前采用版本、物化目标、迭代日志、失败归因和下一步。
- `refs/`外部参考图、用户提供素材、GPT 阶段4提到的参考需求。
- `iterations/`保存每轮试跑的提示词、图片、review 和修改判断。
不同媒介的物化重点:
| 类型 | `visual-system/` 重点 |
| --- | --- |
| 培训 / 科普 AI PPT | 封面模板、章节页模板、概念页模板、案例页模板、图示风格、公式 / 图表 / 文字承载策略 |
| 客户方案 PPT | 商务视觉基调、页面密度、客户决策路径图示、价值证明图示、品牌和留白规则 |
| 科普视频 / PPT式视频 | 公共画面基调、统摄性隐喻、视觉母题、图示风格、页面文字 / 字幕 / 图表承载策略 |
| MV / 剧情 / 人物连续性 | 人物身份锚点、服装锚点、姿态锚点、场景锚点、道具锚点、光线和情绪色彩 |
注意:
- `generate reference assets` 并入本阶段。
- `review and iterate visual system` 并入本阶段。
- 视觉系统可以迭代多轮,不要求第一轮固定。
- 只有 `visual-system.md` 的“当前接受版本”中记录的内容,才算项目级公共视觉系统已接受版本。
### 4. Generate And Iterate Units
这一阶段不采用“一次性生成全套 Prompt再批量执行”的方式。
默认策略是小批次试错、小批次迭代:
```text
先选 1 / 5 / 7 等代表性页面或镜头
→ 生成这些单元的提示词和图片
→ review
→ 需要则进入二稿
→ 通过后再选 2 / 4 / 8 等下一批
→ 最后处理剩余单元
```
批次策略写在:
```text
projects/<project-id>/execution-plan.md
```
单元执行事实写在:
```text
projects/<project-id>/slides/slides.md
```
两者分工:
| 文件 | 记录什么 | 不记录什么 |
| --- | --- | --- |
| `execution-plan.md` | 当前试错策略、批次安排、轮次状态、下一步判断 | 不展开每个单元的完整执行文件 |
| `slides/slides.md` | 每个页面 / 镜头的具体执行状态 | 不替代项目级试错策略 |
| `slides/sNN/` | 单个页面 / 镜头的提示词、图片、review、metadata | 不保存其他单元的资产 |
`slides/slides.md` 建议记录:
```md
| unit | source | batch | spec | prompt | image | review | accepted | notes |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| s01 | GPT stage5 row 1 | batch-01 | done | v2 | v2 | pass | yes | uses visual-system v1 |
| s05 | GPT stage5 row 5 | batch-01 | done | v1 | v1 | revise | no | composition too dense |
```
每个 `slides/sNN/` 目录的文件名必须带 `sNN` 前缀。
示例:
```text
projects/<project-id>/slides/s03/
s03-metadata.json
s03-unit-spec.md
s03-visual-brief.md
s03-v1-prompt.md
s03-v1-image.png
s03-v1-review.md
s03-v2-prompt.md
s03-v2-image.png
s03-v2-review.md
s03-final-notes.md
```
规则:
- 不使用无前缀的 `image-prompt.md`、`review-notes.md`、`metadata.json` 作为默认命名。
- 多个单元同时打开时,文件名本身必须能识别属于哪个页面或镜头。
- 迭代文件采用 `sNN-vN-type.ext`,让同一版本的 prompt、image、review 排在一起。
- 如果同一单元有多张资产,也继续带前缀和版本,例如 `s03-v1-diagram.png`、`s03-v1-background.png`。
- `sNN-unit-spec.md` 来自 GPT 阶段5和本地执行计划不是最终 Prompt。
- `sNN-vN-prompt.md` 才是 Codex 生成的最终图像提示词。
### 5. Closeout When Needed
默认不设置独立的:
```text
export_final_assets
write_project_handoff
```
平时续作依赖:
- `project.md`
- `execution-plan.md`
- `visual-system/visual-system.md`
- `slides/slides.md`
- `slides/sNN/` 内文件
只有以下情况才写 handoff
- 跨线程继续;
- 长时间暂停;
- 项目交付给其他工具或人;
- 需要形成阶段性归档;
- 强哥明确要求。
handoff 可放在项目内或 repo 级 `handoff/`,按实际上下文决定。
## 四、媒介分支流程
### 1. 培训 / 科普 AI PPT
默认流程:
```text
Intake Locked
→ execution-plan.md
→ visual-system/ 固定页面模板和图示系统
→ 代表页小批次试跑
→ slides/sNN/ 逐页生成和迭代
```
重点:
- 页面模板先于全量页面生成;
- 代表页应覆盖概念页、案例页、练习页、图表页;
- 文字、公式、图表、标签可以由 PPT 层、图像层或后期层承载,由 Codex 在执行计划中判断;
- 不设置“图片不能有文字”的全局规则。
### 2. 客户方案 PPT
默认流程:
```text
Intake Locked
→ execution-plan.md
→ visual-system/ 固定商务质感、页面密度和图表规则
→ 决策关键页小批次试跑
→ slides/sNN/ 逐页生成和迭代
```
重点:
- 先试封面、客户痛点页、关键判断页、方案结构页、价值证明页;
- 视觉资产必须服务客户决策;
- 不把 PPT 页当成视频镜头。
### 3. 科普视频 / PPT式视频
默认流程:
```text
Intake Locked
→ execution-plan.md
→ visual-system/ 固定公共画面基调、视觉母题和图示风格
→ 认知关键镜头小批次试跑
→ slides/sNN/ 逐镜头生成和迭代
```
重点:
- 先试开场、核心机制解释、反转、总结升维等关键镜头;
- 口播和画面功能要匹配;
- 画面不是口播装饰;
- 是否出现文字、公式、图表,由解释任务决定。
### 4. MV / 剧情 / 人物连续性
默认流程:
```text
Intake Locked
→ execution-plan.md
→ visual-system/ 固定人物、服装、姿态、场景、道具和情绪色彩
→ 高风险镜头小批次试跑
→ slides/sNN/ 逐镜头生成和迭代
```
重点:
- `makeup-still/` 作废,不再作为独立目录;
- 人物定妆只是 `visual-system/characters/` 的一部分;
- 先固定多锚点参考资产,再做镜头;
- 高风险镜头包括人物近景、全身、动作、跨场景、情绪变化、多人关系。
### 5. 文章 / 口播 / 纯文本
默认不走完整视觉流程。
如果没有图片、PPT、视频页面、MV 或视觉资产需求,可以不创建:
- `visual-system/`
- `slides/`
如果后续要转成视频、PPT 或音频可视化,再进入对应视觉流程。
## 五、目录2.0
推荐项目结构:
```text
projects/<project-id>/
project.md
intake/
execution-plan.md
visual-system/
visual-system.md
refs/
iterations/
slides/
slides.md
s01/
s01-metadata.json
s01-unit-spec.md
s01-visual-brief.md
s01-v1-prompt.md
s01-v1-image.png
s01-v1-review.md
s02/
```
条件目录:
```text
visual-system/characters/
visual-system/scenes/
visual-system/templates/
visual-system/diagrams/
visual-system/backgrounds/
```
不再推荐:
```text
projects/<project-id>/makeup-still/
```
## 六、文件职责
### `project.md`
轻量项目地图。
记录:
- 项目状态;
- 媒介类型;
- `intake/` 文件列表;
- 当前执行焦点;
- 关键文件链接;
- 下一步。
不记录完整执行计划,不复制 GPT 策划稿。
### `execution-plan.md`
项目级执行活文档。
记录:
- Codex 如何解析 GPT V2 阶段0-5
- 本项目属于哪个媒介分支;
- 阶段4要先物化哪些公共视觉系统
- 当前采用什么小批次试错策略;
- 当前跑到第几轮;
- 哪些单元进入当前批次;
- 下一步做什么;
- 哪些判断已被强哥接受。
它是旧 GPT JSON 消失后的本地核心控制文件。
### `visual-system/visual-system.md`
公共视觉系统的当前状态、物化计划和迭代记录。
记录:
- 当前已接受的公共视觉系统;
- 需要物化的视觉目标;
- 每轮试跑了什么;
- 使用了哪些提示词;
- 生成了哪些参考资产;
- review 发现了什么问题;
- 失败归因是什么;
- 哪些版本被接受;
- 当前公共视觉系统使用哪个版本。
### `slides/slides.md`
页面 / 镜头执行明细表。
记录:
- 每个 `sNN` 的来源;
- 属于哪个批次;
- 当前 prompt 版本;
- 当前图片版本;
- review 状态;
- 是否通过;
- 备注。
不承担项目级批次策略。
### `slides/sNN/`
单个页面 / 镜头资产目录。
所有文件名必须带 `sNN` 前缀。
## 七、稳定文档后续改造
本草案确认后,应再更新 video-workbench 的稳定文档。
优先改:
```text
README.md
VIDEO_WORKBENCH.md
docs/context-handoff.md
```
重点改动:
- 把 `GPT = execution packages` 改为 `GPT V2 = 阶段0-5策划 Markdown`
- 把 `Codex = execution` 扩展为 `Codex = 阶段6以后本地执行、Prompt Advisor、视觉系统物化、资产迭代和落盘`
- 去掉对 GPT JSON、Prompt、路径任务单的期待
- 增加 `execution-plan.md`
- 增加 `visual-system/visual-system.md`
- 明确 `makeup-still/` 不再作为推荐目录;
- 明确 `slides/sNN/` 文件名前缀和版本命名规则;
- 增加 `docs/cases/`,承接旧 `30_CASE` / `31_CASE` 的本地化案例模式。
可新增稳定文档:
```text
docs/gpt-v2-local-execution-workflow.md
docs/visual-system-materialization.md
docs/unit-iteration-and-progress.md
docs/cases/README.md
docs/cases/science-video-page-style-case.md
docs/cases/training-ai-ppt-case.md
```
是否新增这些文档,等本草案确认后再决定。
`docs/cases/` 的定位不是复制旧 GPT 知识库,而是从旧真实案例中抽取 Codex 本地执行可用的模式:
- 科普视频的页面化表达颗粒度;
- 培训 PPT 的教学单元设计;
- 页面文字、视觉资产、讲师备注的分层;
- 分镜 / 页面 review 的判断维度。
不继承:
- GPT 直接输出最终图像 Prompt
- GPT 输出 Codex JSON
- 旧路径和旧执行包字段;
- `no readable text` 全局规则。
## 八、硬规则
1. Codex 不向 GPT 索要最终 Prompt。
2. Codex 不向 GPT 索要 Codex JSON。
3. Codex 不把 GPT V2 Markdown 当成执行命令。
4. `execution-plan.md` 是视觉类项目默认必备文件。
5. `visual-system/visual-system.md` 是公共视觉系统的状态、计划和迭代记录统一文件。
6. `makeup-still/` 作废,不再作为推荐目录。
7. 不要求一次性生成全套页面 / 镜头 Prompt。
8. 默认采用小批次试错、小批次迭代。
9. `slides/slides.md` 记录单元执行事实,不替代项目级执行计划。
10. `slides/sNN/` 下所有文件名必须带 `sNN` 前缀,迭代文件采用 `sNN-vN-type.ext`
11. 不把 `no readable text` 当成全局图片规则。
12. 是否由图片承载文字、公式、标签、图表,由 Codex 根据媒介和内容目标在执行层判断。
13. `export_final_assets``write_project_handoff` 按需执行,不作为默认阶段。
14. 旧 `30_CASE` / `31_CASE` 只能抽取为 `docs/cases/` 的案例模式,不作为旧 Prompt / JSON 流程回流入口。
## 九、验收标准
本草案被接受时,应满足:
- 能从 GPT V2 阶段0-5 Markdown 自然进入 Codex 本地执行;
- 不依赖 GPT Prompt、JSON 或路径任务单;
- `execution-plan.md` 的职责清楚;
- `visual-system/` 的职责清楚;
- `makeup-still/` 已从推荐目录中移除;
- 支持小批次试错,而不是全量 Prompt 先行;
- `slides/slides.md``slides/sNN/` 的职责分离清楚;
- `slides/sNN/` 文件名前缀和版本命名规则明确;
- 旧案例进入 `docs/cases/` 的定位清楚;
- PPT、科普视频、MV / 剧情、纯文本任务有合理分支;
- 没有把 GPT 给出的参考流程机械照搬成本地流程。

View File

@ -0,0 +1,46 @@
# GPT Image 2 Advisor Prompt Quality Investigation V2
## Why V2 Exists
The first investigation over-weighted character / MV identity scenarios. That made the result too narrow for the user's actual video-workbench usage.
This V2 uses source scenes from:
- `C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\GPT\强哥的策划导演\30_CASE_典型视频分镜案例.md`
- `C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\GPT\强哥的策划导演\31_CASE_典型培训AI_PPT案例.md`
The weighted priority is:
```text
典型视频分镜(科普) > 典型培训AI > 人物造型
```
## Test Scope
This is only a prompt-quality investigation. It does not generate images and does not claim final image quality.
The current environment is still treated as `gpt-image-2` Advisor / Mode C for this investigation: prompt generation and comparison only.
## Case Mix
| Group | Weight | Cases |
| --- | ---: | --- |
| Science video storyboard | 55% | S-01 AI wave, S-03 AI float vs ocean, S-05 logic sandcastle, S-07 three brakes |
| Training AI PPT | 35% | P8 prompt engineering vs cognitive engineering, P12 score vs growth-state assessment, P18 education AI logic chain |
| Character / makeup-still | 10% | lightweight directory-boundary sample only |
## Files
- `cases.md`: source-derived cases and evaluation intent.
- `outputs/direct-prompts.md`: baseline prompts from or modeled closely on the GPT case files.
- `outputs/advisor-prompts.md`: Advisor-style prompts using `gpt-image-2` structure and relevant templates.
- `提示词质量综合调研报告.md`: weighted comparison and conclusion.
## Template References Used
- `gpt-image-2/SKILL.md`
- `references/prompt-writing.md`
- `references/slides-and-visual-docs/dense-explainer-slides.md`
- `references/slides-and-visual-docs/educational-diagram-slide.md`
- `references/infographics/comparison-infographic.md`
- `references/scenes-and-illustrations/concept-scene.md`

View File

@ -0,0 +1,127 @@
# Cases
## Source Principle
The cases are taken from the two user-specified GPT knowledge files. They are not newly invented story scenarios.
## Group A: Science Video Storyboard, Weight 55%
### V-S01: 被浪拍下水的人
Source: `30_CASE_典型视频分镜案例.md`, S-01.
Intent:
- Opening hook for a science / commentary video.
- Establish the metaphor that ordinary people are being pushed into the AI wave.
- Page text will be added outside the generated image.
Prompt risk:
- AI symbols become literal text.
- The scene becomes a disaster movie instead of a metaphorical visual essay.
- The composition leaves no title-safe area.
### V-S03: 游泳圈与太平洋
Source: `30_CASE_典型视频分镜案例.md`, S-03.
Intent:
- Governing metaphor: AI float vs the Pacific Ocean.
- Show scale contrast: tool is light, reality is vast and heavy.
Prompt risk:
- The ring becomes too cute or too central.
- Ocean scale does not dominate.
- The metaphor turns into a travel poster.
### V-S05: 逻辑沙堡
Source: `30_CASE_典型视频分镜案例.md`, S-05.
Intent:
- Risk visualization: beautiful AI-generated business logic may collapse under reality.
- Sandcastle must look precise and fragile; the wave must feel imminent.
Prompt risk:
- Business-plan elements become readable text.
- The sandcastle looks like a fairy-tale castle rather than fragile logic.
- The wave lacks pressure.
### V-S07: 防忽悠三板斧
Source: `30_CASE_典型视频分镜案例.md`, S-07.
Intent:
- Practical framework: three brakes before using AI for high-stakes action.
- Visualize calculation, red-team attack, and stop-loss rule as three gates / brakes.
Prompt risk:
- The three mechanisms are unclear.
- Text is rendered into the image.
- The image becomes a generic car safety ad.
## Group B: Training AI PPT, Weight 35%
### T-P8: 提示词工程已死?认知工程才刚开始
Source: `31_CASE_典型培训AI_PPT案例.md`, P8.
Intent:
- Training slide contrast: old prompt tricks vs cognitive engineering.
- Left/right comparison visual; final page text handled by PPT layer.
Prompt risk:
- The image tries to render the page text.
- The contrast is too decorative and not teachable.
- "Cognitive core" becomes a generic sci-fi brain.
### T-P12: 从分数评价到成长状态评价
Source: `31_CASE_典型培训AI_PPT案例.md`, P12.
Intent:
- Training slide contrast: result scoring vs growth-state assessment.
- Explain a move from static score sheets to dynamic learning path / feedback maps.
Prompt risk:
- The left side becomes unreadable score-sheet text.
- The right side becomes generic data visualization.
- The visual loses the teacher / student / AI assessment triangle.
### T-P18: AI教育变革的逻辑链
Source: `31_CASE_典型培训AI_PPT案例.md`, P18.
Intent:
- Summary slide: one logic chain from AI ecosystem to cognitive model to CCPE / SPGM to assessment innovation and human-AI education ecology.
Prompt risk:
- Five nodes lose their sequence.
- The image renders fake labels.
- The chain looks like generic "AI transformation" marketing art.
## Group C: Character / Makeup Still, Weight 10%
### C-01: 人物形象目录边界样本
Intent:
- Keep one lightweight character sample only to evaluate whether Advisor prompts support the proposed `makeup-still/` directory.
Prompt risk:
- Overgeneralizing character workflow into all video-workbench work.
- Mistaking character prompt quality for the whole system's quality.

View File

@ -0,0 +1,374 @@
# Advisor Prompts
These prompts apply `gpt-image-2` Advisor structure: type, goal, layout, subject / scene, style, constraints, and production-use notes.
## V-S01 Advisor: 被浪拍下水的人
```json
{
"type": "science video metaphor still / opening hook",
"goal": "Create a 16:9 visual asset for a PPT-style science video opening. The image must carry the metaphor 'ordinary people are being pushed into the AI wave'; final Chinese page text will be added by the video/PPT layer.",
"source_scene": {
"scene_id": "S-01",
"visual_role": "opening_hook",
"core_metaphor": "AI wave pushes ordinary people into the water"
},
"composition": {
"aspect_ratio": "16:9",
"foreground": "several ordinary people being hit by a huge dark-blue wave; at least one person still holding a phone",
"midground": "one bright inflatable ring as the only light playful object, clearly small compared with the wave",
"background": "towering ocean wave mixed with faint AI-era visual fragments",
"title_safe_area": "leave upper-left or lower-left negative space for two lines of overlay text",
"camera": "wide cinematic editorial angle, people small enough to show pressure from the environment"
},
"visual_symbols": {
"ai_fragments": "subtle non-readable UI thumbnails, chat-window silhouettes, image-generation thumbnails, code-like light fragments",
"symbol_rule": "symbols should be recognizable by shape, not by readable words"
},
"style": {
"rendering": "cinematic editorial illustration, metaphorical visual essay",
"palette": "dark blue ocean, black-blue shadows, small warm amber highlights",
"lighting": "dramatic but clean, not horror, not action-movie spectacle"
},
"constraints": {
"must_keep": [
"wave pressure is the dominant visual force",
"people feel like ordinary users, not heroes",
"AI elements are subtle background fragments",
"composition supports page text overlay"
],
"avoid": [
"readable text, logos, watermarks",
"literal AI word labels on objects",
"monster-wave disaster movie style",
"too many UI fragments that make the image cluttered",
"cheerful tech marketing mood"
]
}
}
```
## V-S03 Advisor: 游泳圈与太平洋
```json
{
"type": "science video governing metaphor still",
"goal": "Create a 16:9 visual asset that explains the governing metaphor: a light AI float is not enough for the vast Pacific of reality.",
"source_scene": {
"scene_id": "S-03",
"visual_role": "governing_metaphor",
"core_metaphor": "tool is light, reality is vast and heavy"
},
"composition": {
"aspect_ratio": "16:9",
"subject_scale": "the human figure must be small; ocean and sky occupy at least 75% of the frame",
"foreground": "shallow water edge, a small human holding a bright inflatable ring",
"midground": "boundary line from shallow water to dark deep water",
"background": "vast dark ocean under storm clouds, horizon feels far and overwhelming",
"camera": "wide low-distance composition, strong scale contrast",
"title_safe_area": "keep one clean area for overlay text"
},
"style": {
"rendering": "cinematic metaphorical illustration",
"palette": "dark blue, blue-black ocean, gray storm sky, one controlled bright ring accent",
"mood": "sobering, not heroic, not inspirational travel"
},
"constraints": {
"must_keep": [
"human must look tiny",
"ocean must feel immense and risky",
"float must look light, almost absurd",
"image must serve the governing metaphor"
],
"avoid": [
"travel poster beauty",
"cute beach vacation",
"person centered as hero",
"readable text, logos, watermarks",
"oversaturated ring that dominates the frame"
]
}
}
```
## V-S05 Advisor: 逻辑沙堡
```json
{
"type": "science video risk visualization still",
"goal": "Create a 16:9 metaphor image: a beautiful AI-generated business plan may be only a fragile logic sandcastle before reality hits.",
"source_scene": {
"scene_id": "S-05",
"visual_role": "risk_visualization",
"core_metaphor": "beautiful logical plan vs reality wave"
},
"composition": {
"aspect_ratio": "16:9",
"foreground": "a highly detailed sandcastle built like a fragile business architecture: towers, bridges, tiny pathways, neatly arranged but clearly made of sand",
"supporting_objects": "scattered abstract chart pages and planning diagrams near the sandcastle, only visual marks, no readable text",
"background": "large dark-blue wave curling toward the sandcastle, close enough to feel imminent",
"camera": "three-quarter low angle so the sandcastle looks impressive but vulnerable",
"title_safe_area": "leave clean upper area or sky area for overlay text"
},
"style": {
"rendering": "metaphorical cinematic editorial illustration",
"palette": "warm sand / gold foreground against dark blue wave",
"lighting": "beautiful foreground light interrupted by threatening cool shadow from the wave"
},
"constraints": {
"must_keep": [
"sandcastle is precise, complex, and fragile",
"wave has imminent destructive pressure",
"contrast between beautiful logic and harsh reality is obvious",
"business-plan symbols remain non-readable"
],
"avoid": [
"fairy-tale castle made of stone",
"calm decorative beach",
"readable charts or documents",
"wave too far away",
"cartoon comedy tone"
]
}
}
```
## V-S07 Advisor: 防忽悠三板斧
```json
{
"type": "science video practical framework still",
"goal": "Create a 16:9 educational metaphor image showing three brakes before high-stakes AI action.",
"source_scene": {
"scene_id": "S-07",
"visual_role": "practical_framework",
"framework_items": ["risk calculation", "red-team attack", "stop-loss rule"]
},
"composition": {
"aspect_ratio": "16:9",
"main_scene": "a small vehicle rushing toward a cliff edge that drops into a deep dark ocean",
"safety_structure": "three clearly separated glowing brake gates between the vehicle and danger",
"gate_1": "calculator / ledger icon for risk calculation",
"gate_2": "cyber watchdog / red-team icon for attack and critique",
"gate_3": "cold contract / stop sign / signed paper icon for stop-loss rule",
"flow": "left-to-right or foreground-to-background progression: vehicle -> three gates -> danger",
"title_safe_area": "keep a clear overlay area for two lines of page text"
},
"style": {
"rendering": "cinematic educational illustration, clean symbolic structure",
"palette": "dark blue risk zone, warm amber gate light, neutral vehicle",
"mood": "tense but practical, clear, not cartoonish"
},
"constraints": {
"must_keep": [
"three mechanisms are visually distinct",
"danger ahead is clear",
"gates visibly stop the vehicle",
"icons communicate without readable words"
],
"avoid": [
"readable Chinese or English labels",
"generic traffic safety poster",
"overly cute watchdog",
"more than three gates",
"cluttered UI elements"
]
}
}
```
## T-P8 Advisor: 提示词工程已死?认知工程才刚开始
```json
{
"type": "training PPT comparison visual asset",
"goal": "Create a 16:9 visual asset for a training slide comparing old prompt tricks with cognitive engineering. The PPT layer will render all final readable text.",
"source_page": {
"slide_id": "P8",
"teaching_goal": "Show that low-level prompt tricks are aging, while structured expert cognition becomes more important."
},
"layout": {
"page_type": "two-column comparison",
"left_column": {
"role": "old prompt engineering",
"visual": "scattered prompt cards, broken magic-scroll metaphor, loose snippets and role-play masks fading out",
"mood": "fragmented, clever but shallow"
},
"right_column": {
"role": "cognitive engineering",
"visual": "structured cognitive core / knowledge engine with process loops, evaluation nodes, domain layers, feedback arrows",
"mood": "ordered, durable, expert-like"
},
"transition": "central arrow or transformation bridge from left to right",
"title_safe_area": "top band left empty enough for slide title"
},
"style": {
"rendering": "clean academic training slide illustration",
"palette": "muted gray on left, deep blue and warm gold on right, off-white background",
"information_density": "medium-high, but not a final text slide"
},
"constraints": {
"must_keep": [
"clear left/right contrast",
"visual logic supports later overlay labels",
"cognitive core must show structure: loops, layers, standards",
"no final readable text generated in image"
],
"avoid": [
"generic sci-fi brain without teaching meaning",
"too much fake text",
"magic fantasy dominates the left side",
"marketing-poster hero composition",
"logos or watermarks"
]
}
}
```
## T-P12 Advisor: 从分数评价到成长状态评价
```json
{
"type": "training PPT assessment comparison visual asset",
"goal": "Create a 16:9 training-slide visual comparing static score evaluation with dynamic growth-state assessment. Final labels are added by PPT tooling.",
"source_page": {
"slide_id": "P12",
"teaching_goal": "Help the audience see that intelligent assessment identifies learning process and growth state, not only final score."
},
"layout": {
"page_type": "two-column contrast with transition arrow",
"left_column": {
"role": "traditional result scoring",
"visual": "cold static score sheet silhouette, ranking bars, checkmarks and red marks as abstract shapes, no readable numbers",
"mood": "flat, final, judgment-oriented"
},
"right_column": {
"role": "AI + SPGM growth-state assessment",
"visual": "dynamic growth map with student learning path, thinking nodes, teacher feedback loops, AI analysis lines, state changes over time",
"mood": "warm, developmental, process-oriented"
},
"transition": "arrow from result-only to process-plus-state",
"title_safe_area": "top area available for slide title and subtitle"
},
"style": {
"rendering": "clean educational diagram slide, human-centered technology",
"palette": "cool gray for left, warm blue-green and gold for right, off-white canvas",
"information_density": "medium-high with readable visual hierarchy"
},
"constraints": {
"must_keep": [
"left side feels static and score-based",
"right side shows learning path, teacher feedback, and AI analysis as connected system",
"contrast is understandable without final text",
"no generated paragraphs or fake score details"
],
"avoid": [
"generic dashboard",
"unreadable tiny tables",
"teacher/student elements missing from the growth map",
"overly corporate analytics style",
"logos or watermarks"
]
}
}
```
## T-P18 Advisor: AI教育变革的逻辑链
```json
{
"type": "training PPT logic-chain visual asset",
"goal": "Create a 16:9 summary-slide visual showing the logic chain of AI education transformation. Final text labels are added outside the generated image.",
"source_page": {
"slide_id": "P18",
"teaching_goal": "Help the audience review the full lecture as one cognitive chain."
},
"layout": {
"page_type": "horizontal logic chain",
"node_count": 5,
"nodes": [
{
"id": 1,
"role": "AI ecosystem change",
"visual": "education ecosystem network icon: school, students, teachers, AI tools"
},
{
"id": 2,
"role": "expert cognitive model",
"visual": "structured thinking model / layered knowledge core"
},
{
"id": 3,
"role": "CCPE",
"visual": "expert thinking entering AI through structured protocol layers"
},
{
"id": 4,
"role": "SPGM and assessment innovation",
"visual": "matrix / growth-state map with teacher-student interaction"
},
{
"id": 5,
"role": "human-AI collaborative education ecology",
"visual": "school ecosystem with teacher, student, AI assistant, feedback loops"
}
],
"connectors": "thin luminous arrows from left to right, each node visually distinct but same style",
"title_safe_area": "top band empty enough for title and core conclusion"
},
"style": {
"rendering": "elegant keynote presentation visual, educational technology, clean vector-like illustration",
"palette": "academic blue, warm gold accents, soft off-white background",
"information_density": "medium, designed for overlay text"
},
"constraints": {
"must_keep": [
"exactly five main nodes",
"left-to-right sequence is unambiguous",
"each node has a distinct visual role",
"chain ends in education ecology, not generic AI future"
],
"avoid": [
"fake readable labels inside the image",
"generic AI marketing network",
"node count drifting from five",
"overly complex background",
"logos or watermarks"
]
}
}
```
## C-01 Advisor: 人物形象目录边界样本
```json
{
"type": "makeup-still directory boundary sample",
"goal": "Create a prompt that would belong under projects/<project-id>/makeup-still/ only when a project has a recurring human or character identity system. This is a low-weight boundary sample, not a core use case.",
"subject": {
"identity": "50-year-old East Asian male knowledge worker",
"fixed_markers": ["black rectangular glasses", "natural stubble", "tired but steady eyes", "slightly messy hair"],
"wardrobe_hint": "dark jacket or coat, understated"
},
"composition": {
"shot": "neutral head-and-shoulders identity reference",
"background": "plain gray or lightly blurred office-like neutral background",
"use": "identity_ref for future generated visuals, not final slide artwork"
},
"style": {
"rendering": "photorealistic reference portrait, natural light, no glamour"
},
"constraints": {
"must_keep": [
"stable identity markers",
"usable as a reference asset",
"plain enough for reuse"
],
"avoid": [
"turning this into a universal workflow for non-character projects",
"hero poster or fashion portrait",
"readable text, logo, watermark"
]
}
}
```

View File

@ -0,0 +1,35 @@
# Direct Prompts
These are the baseline direct prompts. For the science-video and training-PPT cases, they are taken from or kept close to the GPT case-file prompt style.
## V-S01 Direct: 被浪拍下水的人
A cinematic metaphorical illustration of ordinary people being swept into a huge dark blue ocean wave filled with subtle AI symbols, video thumbnails, chat windows, code fragments, and glowing digital particles. One person clutches a bright inflatable ring labeled conceptually as AI without readable text. Dramatic lighting, deep blue water, high tension, human-centered technology theme, editorial visual essay style, no readable text, 16:9.
## V-S03 Direct: 游泳圈与太平洋
A small human figure holding a bright inflatable ring symbolizing AI, standing at the edge of shallow water and facing a vast dark ocean under a stormy sky. The ocean feels enormous, dangerous, and overwhelming. Strong contrast between the playful floating ring and the terrifying deep sea. Cinematic metaphorical illustration, dark blue palette, dramatic clouds, no readable text, 16:9.
## V-S05 Direct: 逻辑沙堡
A highly detailed sandcastle on a beach, shaped like a complex business plan with towers, bridges, charts, and fragile pathways, while a huge ocean wave is about to crash into it. Scattered elegant business plan pages and diagrams lie nearby, but no readable text. Metaphorical cinematic illustration, dramatic tension, golden beach light with dark blue wave, no readable text, 16:9.
## V-S07 Direct: 防忽悠三板斧
A metaphorical scene of a small vehicle about to rush toward a dangerous cliff and deep ocean, stopped by three glowing brake gates. The three gates are represented by icons: a calculator for risk calculation, a cyber watchdog for red-team attack, and a signed cold contract for stop-loss rules. Cinematic educational illustration, dark blue and amber palette, no readable text, 16:9.
## T-P8 Direct: 提示词工程已死?认知工程才刚开始
Split-screen conceptual illustration: on the left, scattered old prompt cards and broken magic scrolls fading away; on the right, a glowing structured cognitive core shaped like a brain with connected process loops, evaluation nodes, and domain knowledge layers, futuristic academic style, clean composition, no readable text, 16:9.
## T-P12 Direct: 从分数评价到成长状态评价
Split-screen educational assessment illustration: left side a traditional static score sheet and ranking chart, right side a dynamic growth map with student learning paths, thinking nodes, teacher feedback loops, and AI analysis lines, warm human-centered technology style, no readable text, 16:9.
## T-P18 Direct: AI教育变革的逻辑链
A clean horizontal logic chain diagram for educational AI transformation, five connected glowing nodes representing AI ecosystem, cognitive engineering, educational model, assessment innovation, and human-AI collaborative school, elegant keynote presentation style, no readable text, 16:9.
## C-01 Direct: 人物形象目录边界样本
Create a realistic reference portrait of a recurring video protagonist: a 50-year-old East Asian male knowledge worker with black rectangular glasses, natural stubble, tired but steady eyes, slightly messy hair, and a dark jacket. Clean neutral background, realistic lighting, no readable text.

View File

@ -0,0 +1,232 @@
# 提示词质量综合调研报告
## 结论
在只评估提示词质量、不生成图片的前提下,`gpt-image-2` Advisor 工作流仍然明显优于直接 prompt。
这次结论比 v1 更稳,因为样本权重已调整为:
```text
典型视频分镜(科普) 55%
典型培训AI PPT 35%
人物造型 10%
```
并且科普视频和培训 PPT 的 baseline 不是弱 prompt而是直接采用或贴近 GPT 知识库两个典型案例中的已有生图 prompt。
综合加权结果:
| Prompt 类型 | 加权平均分 / 30 |
| --- | ---: |
| 直接 prompt | 21.6 |
| Advisor prompt | 27.9 |
核心判断:
> Advisor 的优势不主要在“更会写画面形容词”,而在“把视频 / PPT 生产所需的结构、约束、版面安全区、文字责任边界和失败风险写进 prompt”。
## 调研依据
本报告使用两个指定案例:
- `30_CASE_典型视频分镜案例.md`
- `31_CASE_典型培训AI_PPT案例.md`
关键案例规则包括:
- 科普视频图片不负责正文文字,页面文字由 PPT / 视频页面层渲染。
- 每个科普分镜只承载一个核心逻辑点,画面必须承担隐喻表达。
- 培训 PPT 页不是镜头,而是教学单元,需要支持讲师停留、解释、提问和迁移。
- 培训 PPT 的页面设计、讲师备注和生图 prompt 必须分开。
这些规则与 `gpt-image-2` Advisor 方法匹配:将图像请求拆成 `type / goal / layout / subject / scene / style / constraints`,并避免让图像模型生成最终可读正文。
## 评分 Rubric
每个 case 满分 30 分6 个维度各 0-5 分。
| 维度 | 说明 |
| --- | --- |
| R1 媒介适配 | 是否知道这是科普视频、培训 PPT、还是人物参考而不是泛图。 |
| R2 结构控制 | 是否明确布局、景别、前中后景、对比栏、节点链路或标题安全区。 |
| R3 文字责任边界 | 是否避免让图像模型生成正文、标签、分数、中文说明。 |
| R4 隐喻 / 教学逻辑 | 是否服务于单一核心逻辑点或教学目标。 |
| R5 失败预防 | 是否明确常见失败:过度装饰、假文字、图标不清、隐喻漂移。 |
| R6 复用与迭代 | 是否适合落入 video-workbench 的版本化 prompt / review 流程。 |
## 分组结果
### A. 科普视频分镜,权重 55%
| Case | Direct / 30 | Advisor / 30 | 主要差异 |
| --- | ---: | ---: | --- |
| V-S01 被浪拍下水的人 | 23 | 28 | Advisor 明确 opening hook、标题安全区、AI 元素只能用不可读符号。 |
| V-S03 游泳圈与太平洋 | 22 | 28 | Advisor 强化人物小、海洋占比、浅水/深水边界,避免旅游海报化。 |
| V-S05 逻辑沙堡 | 23 | 28 | Advisor 把“精美但脆弱”和“浪头迫近”拆成可检查构图约束。 |
| V-S07 防忽悠三板斧 | 22 | 27 | Advisor 明确三道 gate 的数量、图标角色和车辆-闸门-风险的运动方向。 |
组平均:
| Prompt 类型 | 平均分 / 30 |
| --- | ---: |
| Direct | 22.5 |
| Advisor | 27.8 |
科普视频里的直接 prompt 已经不错,特别是隐喻清楚、画面感强。但 Advisor 在三个地方更稳:
- 更适合后续叠加页面文字,因为会主动保留 title-safe area。
- 更少依赖“形容词堆叠”,更多使用可检查结构。
- 更适合 review因为 acceptance criteria 可以直接从 constraints 中抽取。
### B. 培训 AI PPT权重 35%
| Case | Direct / 30 | Advisor / 30 | 主要差异 |
| --- | ---: | ---: | --- |
| T-P8 提示词工程 vs 认知工程 | 21 | 28 | Advisor 把左右对比、转化桥、页面文字责任拆开,教学用途更清楚。 |
| T-P12 分数评价 vs 成长状态评价 | 21 | 28 | Advisor 明确静态评分与动态成长地图的视觉差异,避免泛数据看板。 |
| T-P18 AI教育变革逻辑链 | 20 | 29 | Advisor 强制五节点链路、节点角色和顺序,避免泛 AI 营销图。 |
组平均:
| Prompt 类型 | 平均分 / 30 |
| --- | ---: |
| Direct | 20.7 |
| Advisor | 28.3 |
培训 PPT 是 Advisor 提升最大的场景。原因很具体:
- 培训页经常有“页面结构 + 可编辑文字 + 视觉资产”三层,直接 prompt 容易混在一起。
- Advisor 会把 `layout`、`title_safe_area`、`no final readable text`、`post-use` 关系写清楚。
- 对模型页、对比页、逻辑链页Advisor 的字段化结构更像可复用的页面资产规范。
### C. 人物造型,权重 10%
| Case | Direct / 30 | Advisor / 30 | 主要差异 |
| --- | ---: | ---: | --- |
| C-01 人物形象目录边界样本 | 20 | 27 | Advisor 明确这是 `makeup-still/` 的低权重边界样本,不扩张成通用流程。 |
人物造型不应再主导本次改造判断。它的价值只在于当项目确实有人物或角色连续性时Advisor 能帮助定义 `identity_ref`、目录边界和复用目的。
## 加权计算
| Group | Weight | Direct Avg | Advisor Avg | Direct Weighted | Advisor Weighted |
| --- | ---: | ---: | ---: | ---: | ---: |
| 科普视频分镜 | 55% | 22.5 | 27.8 | 12.4 | 15.3 |
| 培训 AI PPT | 35% | 20.7 | 28.3 | 7.2 | 9.9 |
| 人物造型 | 10% | 20.0 | 27.0 | 2.0 | 2.7 |
| **Total** | **100%** | | | **21.6** | **27.9** |
## 质量差异归因
### 1. Advisor 更能保住“图片不负责正文文字”
两个指定案例都强调:页面正文、标题、金句由 PPT / 视频页面层渲染,图片 prompt 只生成背景、视觉隐喻或图示资产。
直接 prompt 虽然常写 `no readable text`但经常同时要求“score sheet / ranking chart / logic chain / prompt cards”等文本性对象模型容易生成假字。
Advisor prompt 会进一步说明:
- 只生成 score-sheet silhouette不生成具体分数。
- 只生成 abstract prompt cards不生成可读 prompt。
- 只生成 node visuals不生成节点文字。
- 保留 title-safe area 给后续页面层。
这对培训 PPT 和科普视频都很关键。
### 2. Advisor 更适合“教学单元”
培训 PPT 不是单纯好看,而是要让讲师能停下来讲。
直接 prompt 多数只给一张概念图。Advisor 会补足:
- `teaching_goal`
- `page_type`
- `left_column / right_column`
- `transition`
- `title_safe_area`
- `constraints`
这些字段让图像资产更像“页面组件”,不是独立插画。
### 3. Advisor 更适合“分镜资产”
科普视频分镜需要画面推进和隐喻表达。直接 prompt 的画面描述强,但不总是说明:
- 这个镜头在视频里的角色是什么;
- 需要给叠字留哪里;
- 哪些符号只能作为不可读元素;
- 怎么避免隐喻漂移;
- 后续 review 如何判断通过。
Advisor prompt 会把这些都显式化。
### 4. Advisor 的成本是更长、更工程化
Advisor prompt 不适合所有场景。对于很简单的单主体图,直接 prompt 足够。
但在 video-workbench 高频任务中,主要是科普视频和培训 PPT。这些任务不是“一张漂亮图”而是“可叠字、可讲解、可复用、可 review 的生产资产”。在这个条件下Advisor 的冗长是成本,也是控制力来源。
## 对改造前提的判断
原始前提是:
> Codex 具有 `GPT image 2 skill`,其 Advisor 模式下,如果再叠加 GPT 的知识库,出的图片提示词质量应该比 GPT 高。
本次调研的判断:
```text
在提示词质量层面:成立。
在最终图像质量层面:尚未验证。
```
更准确的表述应改为:
> GPT 负责输出导演卡、教学页设计、分镜意图和验收标准Codex 使用 `gpt-image-2` Advisor 将这些内容转成结构化、可复用、可 review 的图片 prompt。对科普视频和培训 PPT这类 prompt 的生产质量明显高于直接生成一段生图 prompt。
## 对目录和知识库的影响
### 1. `investigations/` 是合适的
这类内容是前提验证,不是项目资产,也不是稳定知识库。放在:
```text
investigations/<date>-<topic>/
```
比放在 `tmp/` 更可追踪,比直接放 `docs/` 更谨慎。
### 2. 稳定知识应进入 `docs/`
如果接受本报告结论,再把稳定规则整理进 `video-workbench/docs/`,例如:
```text
docs/image-prompt-advisor-workflow.md
docs/visual-asset-prompt-rubric.md
docs/page-text-vs-image-prompt-boundary.md
docs/makeup-still-directory-policy.md
```
其中前 3 个比 `makeup-still` 更重要,因为科普和培训才是主场景。
### 3. `makeup-still/` 应是条件目录
建议保留你的设想,但不要作为所有项目默认目录。
```text
projects/<project-id>/makeup-still/
```
只在人、角色、讲师形象、IP 形象需要跨镜头 / 跨页保持一致时出现。
## 后续验证建议
当前只关心提示词质量,因此本报告可以作为进入“分工与目录改造草案”的前置依据。
如果后面要验证最终图像质量,再做 Level 2
1. 从本报告选 2 个科普视频 prompt、2 个培训 PPT prompt。
2. 同平台、同参数分别出图。
3. 用同一 acceptance criteria 评估成图。
4. 记录 Advisor 是否实际降低假文字、构图漂移和隐喻失焦。
本轮不需要做 Level 2。

View File

@ -0,0 +1,51 @@
# GPT Image 2 Advisor Prompt Quality Investigation
## Purpose
This investigation tests a workflow premise before any GPT / video-workbench restructuring:
> If Codex uses the `gpt-image-2` skill in Advisor mode and combines it with the accepted GPT director knowledge, the resulting image prompts should be stronger than ordinary GPT direct prompts.
This is a prompt-text quality test only. It does not validate final image quality because no image generation is performed.
## Scope
The test compares two prompt styles across five representative video-workbench scenes:
1. Direct prompt: a normal prompt written without consulting `gpt-image-2` templates.
2. Advisor prompt: a prompt rendered after reading the relevant `gpt-image-2` skill guidance and templates.
The current environment was checked with the skill's mode detector. It returned `B-or-C`, with Garden disabled and no local API key. This investigation forces Mode C / Advisor: save and compare prompts only.
## Skill References Read
- `gpt-image-2/SKILL.md`
- `references/prompt-writing.md`
- `references/portraits-and-characters/professional-portrait.md`
- `references/portraits-and-characters/character-sheet.md`
- `references/portraits-and-characters/pose-reference-sheet.md`
- `references/storyboards-and-sequences/cinematic-storyboard-grid.md`
- `references/scenes-and-illustrations/concept-scene.md`
- `references/slides-and-visual-docs/dense-explainer-slides.md`
## Files
- `mode-check.json`: local mode detection result.
- `cases.md`: test cases and expected prompt risks.
- `outputs/direct-prompts.md`: baseline direct prompts.
- `outputs/advisor-prompts.md`: Advisor-style prompts.
- `comparison.md`: rubric, scores, and conclusion.
## Directory Decision For Future Work
This investigation uses a root-level `investigations/` directory because it is validating an assumption, not running a production project or automated test suite.
If this premise is accepted, stable workflow documentation should move into `docs/`. Project-specific outputs should remain under `projects/<project-id>/`.
For projects with recurring human character imagery, this investigation supports adding:
```text
projects/<project-id>/makeup-still/
```
Use it only when a project has a character / human identity package. It should hold makeup-still prompts, generated or externally produced makeup-still images, reference-role notes, and acceptance records. Projects without visible characters do not need this folder.

View File

@ -0,0 +1,85 @@
# Test Cases
## Evaluation Question
Does the Advisor workflow produce prompts that are more controllable, reusable, and aligned with video-workbench production needs than direct prompting?
## Case T01: Character Identity Makeup Still
Goal: create a stable identity reference image for a recurring MV protagonist.
Input:
- 50-year-old East Asian male traveler.
- Black rectangular glasses, stubble, tired but steady eyes, slightly messy hair.
- Dark long coat, old backpack strap visible.
- Not heroic, not fashion, not influencer portrait.
- Output should become `identity_ref` for later shots.
Main risk:
- If the prompt over-cinematizes the result, the identity anchor becomes too stylized and hard to reuse.
- If the prompt under-specifies face and texture, later shots drift.
## Case T02: Wardrobe / Body Fullbody Anchor
Goal: create a wardrobe and body silhouette reference, not a face reference.
Input:
- Same traveler system as T01.
- Full body or nearly full body.
- Long dark coat length, old backpack, trouser cuffs, muddy boots.
- Face may be less important; outfit continuity is the goal.
Main risk:
- Prompt tries to solve face, wardrobe, mood, and scene at once.
- The result becomes another portrait instead of a silhouette / costume reference.
## Case T03: MV Side-Walking Road Shot
Goal: make a production still for an MV shot where the character walks along a cold road.
Input:
- Use identity_ref for face system, wardrobe_ref for outfit, pose_ref for side / three-quarter walking.
- Environment occupies at least 60%.
- The character should not look into camera.
- Vertical 9:16, road-movie mood, restrained fatigue.
Main risk:
- The identity reference pulls the result back into centered portrait.
- The road scene loses character consistency.
## Case T04: Low-Angle Muddy Boots Detail
Goal: make a close detail shot where identity is carried by boots, coat hem, mud, and bodily cost.
Input:
- Low angle near the ground.
- Muddy boots stepping through wet road.
- Coat hem and backpack strap may appear, face is not required.
- Vertical 9:16, tactile road-movie detail.
Main risk:
- Overusing the face identity reference harms the shot.
- The image becomes a generic boot photo without narrative continuity.
## Case T05: High-Density Explainer Slide Visual
Goal: test a non-character visual common in video-workbench: one dense page explaining a concept.
Input:
- Topic: why AI image production needs staged visual anchors.
- Style: clean training slide / explainer page.
- Output image should be a visual background or slide asset; readable text should be handled outside the generated image.
Main risk:
- Direct prompt asks the image model to render too much text.
- The result may be visually attractive but structurally useless for a slide.

View File

@ -0,0 +1,86 @@
# Comparison
## Rubric
Scores are subjective prompt-text scores from 0 to 5. They judge whether the prompt is likely to be controllable and reusable in video-workbench. They do not judge generated image quality.
| Dimension | Meaning |
| --- | --- |
| D1 Intent Decomposition | Separates goal, subject, scene, and output use. |
| D2 Reference Role Control | Clarifies which reference preserves identity, wardrobe, pose, or style. |
| D3 Composition Specificity | Defines camera, framing, aspect ratio, environment ratio, and motion. |
| D4 Failure Prevention | Names predictable failure modes and avoids them. |
| D5 Workflow Fit | Fits `projects/<project-id>/...` style production records and later review. |
| D6 Model Usability | Gives image models concrete visual instructions without overloading readable text. |
## Scores
| Case | Direct Total / 30 | Advisor Total / 30 | Main Difference |
| --- | ---: | ---: | --- |
| T01 Identity makeup still | 20 | 27 | Advisor treats the result as `identity_ref`, not a final cinematic scene. |
| T02 Wardrobe fullbody anchor | 18 | 27 | Advisor explicitly downgrades face likeness and prioritizes outfit geometry. |
| T03 MV side-walking shot | 19 | 29 | Advisor separates identity, wardrobe, pose, and style references and guards against portrait drift. |
| T04 Muddy boots detail | 22 | 28 | Advisor correctly avoids using identity as the primary reference. |
| T05 Dense explainer slide | 18 | 27 | Advisor prevents the common error of asking the image model to render final readable text. |
Average:
| Prompt Type | Average / 30 |
| --- | ---: |
| Direct | 19.4 |
| Advisor | 27.6 |
## Findings
At the prompt-text level, the Advisor workflow is materially stronger than direct prompting for this use case.
The main improvement is not prettier language. It is production control:
- It states whether an output is an identity anchor, wardrobe anchor, final shot, detail shot, or slide background.
- It splits references into roles instead of treating all references as the same kind of input.
- It encodes known failures from the prior run, especially portrait drift and overusing face identity.
- It creates prompts that can be versioned, reviewed, and revised per shot.
This supports the restructuring premise:
```text
GPT should output director cards and acceptance standards.
Codex / video-workbench should render final image prompts using gpt-image-2 Advisor logic.
```
## Limits
This does not prove final image quality. It proves only that the Advisor prompt artifacts are higher-quality production inputs under a text rubric.
The next validation level should be:
1. Pick 2-3 prompts from this investigation.
2. Generate images on the same image platform.
3. Judge image outcomes with the same acceptance criteria.
4. Record whether the Advisor prompts actually reduce failure rates.
## Path Implications
The investigation supports adding a project-local character package folder for human-character projects:
```text
projects/<project-id>/makeup-still/
identity-prompt-v1.md
identity-ref-v1.png
wardrobe-prompt-v1.md
wardrobe-ref-v1.png
pose-ref-notes.md
acceptance-notes.md
```
This folder should exist only when a project needs a recurring human / character identity system. Non-character projects should not carry the folder.
Stable Codex-side knowledge should not be buried in a single project. After owner acceptance, summarize this into `docs/` as video-workbench operating knowledge, likely:
```text
docs/image-prompt-advisor-workflow.md
docs/makeup-still-directory-policy.md
docs/reference-strategy-and-review-rubric.md
```
Do not write those stable docs before the owner accepts this investigation result.

View File

@ -0,0 +1,12 @@
{
"checked_at": "2026-06-23",
"command": "node C:\\Users\\wangq\\.agents\\skills\\gpt-image-2\\scripts\\check-mode.js --json",
"mode": "B-or-C",
"recommendation": "host-or-advisor",
"garden_mode_enabled": false,
"has_api_key": false,
"base_url": "https://api.openai.com/v1",
"model": "gpt-image-2",
"env_flag_value": "(unset)",
"test_decision": "Force Mode C / Advisor for this investigation. Do not generate images."
}

View File

@ -0,0 +1,283 @@
# Advisor Prompts
These prompts apply `gpt-image-2` Advisor guidance: choose the nearest template family, split fields, define must-keep / avoid constraints, and make reference roles explicit.
## T01 Advisor: Character Identity Makeup Still
```json
{
"type": "character identity makeup still / reusable identity reference",
"goal": "Generate a stable identity reference image for a recurring MV protagonist. The image is not the final MV scene; it will be used as identity_ref in later image-to-image shots.",
"subject": {
"identity": "50-year-old East Asian male traveler",
"face": {
"glasses": "black rectangular glasses",
"hair": "short dark hair, slightly messy, natural not styled",
"facial_hair": "light stubble, uneven and realistic",
"skin": "natural skin texture, visible pores, no plastic smoothing",
"eyes": "tired but steady, restrained emotional weight"
},
"expression": {
"mood": "quiet resilience, fatigue contained rather than dramatized",
"gaze": "neutral forward gaze, not heroic, not influencer-like"
},
"wardrobe_visible": "dark long coat collar and upper chest, old backpack strap visible but secondary"
},
"composition": {
"shot": "head-and-shoulders or upper torso portrait",
"framing": "centered enough for identity reuse, simple background, no dramatic scene action",
"aspect_ratio": "3:4 or vertical 9:16",
"background": "plain cool gray outdoor overcast background, lightly blurred"
},
"style": {
"image_type": "photorealistic makeup still / character reference photo",
"lighting": "soft overcast natural light, low contrast, no glamour rim light",
"color_grading": "cool gray road-movie palette, muted skin tones",
"camera": "85mm portrait lens feel, realistic depth of field"
},
"constraints": {
"must_keep": [
"face identity must be stable and reusable",
"black rectangular glasses are a fixed identity marker",
"stubble, age, and tired eyes must remain visible",
"wardrobe should hint at the traveler system without becoming a fashion shoot"
],
"avoid": [
"hero poster",
"fashion editorial portrait",
"smiling influencer headshot",
"excessive wrinkles or caricatured aging",
"dramatic fantasy lighting",
"readable text, logo, watermark"
]
},
"usage_note": "Use this output as identity_ref only. Do not use it as the sole reference for wide walking shots because it may pull later generations toward portrait framing."
}
```
## T02 Advisor: Wardrobe / Body Fullbody Anchor
```json
{
"type": "wardrobe and body silhouette reference",
"goal": "Generate a reusable wardrobe_ref / body_ref for later MV shots. Face similarity is secondary; clothing geometry, body proportions, and traveler silhouette are primary.",
"subject": {
"character_system": "same 50-year-old East Asian male traveler system as identity_ref",
"visibility": "full body, head to boots, standing in neutral pose",
"priority": {
"highest": "coat length, backpack shape, trouser cuffs, muddy boots, body proportion",
"medium": "age impression, glasses presence",
"lower": "precise facial likeness"
},
"wardrobe": {
"coat": "dark long coat reaching around knee level, worn fabric, not stylish new fashion",
"backpack": "old practical backpack with visible shoulder straps, slightly sagging",
"pants": "dark worn trousers, relaxed fit, cuffs near boots",
"boots": "sturdy muddy travel boots, scuffed leather or canvas"
}
},
"composition": {
"shot": "full-body neutral reference photo",
"camera": "straight-on eye-level, consistent scale, no dramatic perspective",
"pose": "standing or slight walking-ready stance, arms natural, body readable",
"background": "plain light gray or muted outdoor wall, minimal distractions",
"aspect_ratio": "3:4 vertical"
},
"style": {
"image_type": "photorealistic costume continuity reference",
"lighting": "even soft daylight",
"rendering": "clear clothing edges and material texture, not painterly"
},
"constraints": {
"must_keep": [
"full body visible including boots",
"coat length and backpack silhouette clearly readable",
"outfit looks used, practical, and road-worn",
"single subject only"
],
"avoid": [
"tight portrait crop",
"runway fashion styling",
"clean luxury clothes",
"strong action pose that hides outfit structure",
"extra bags or props that confuse continuity",
"readable text, logo, watermark"
]
},
"usage_note": "Use this output as wardrobe_ref. Pair it with identity_ref for face-bearing shots and pose_ref for action/composition shots."
}
```
## T03 Advisor: MV Side-Walking Road Shot
```json
{
"type": "single cinematic MV storyboard still",
"goal": "Generate one vertical 9:16 MV production still from a director card. The shot should feel like a road-movie scene, not a character portrait.",
"reference_strategy": {
"identity_ref": "use only to preserve the recurring character system: 50-year-old East Asian male, black rectangular glasses, stubble, tired steady face",
"wardrobe_ref": "use to preserve long dark coat, old backpack, trouser cuffs, muddy boots, body silhouette",
"pose_ref": "use for side or three-quarter walking posture, gaze toward the road, no direct eye contact",
"style_ref": "cold morning road-movie still, muted gray-blue light, restrained fatigue"
},
"scene": {
"time": "early morning, cold air, thin mist",
"location": "empty rural or suburban road leading into distance",
"weather": "damp road surface, light frost or cold haze",
"emotional_function": "the character is still moving after hardship; fatigue becomes forward motion"
},
"composition": {
"aspect_ratio": "vertical 9:16",
"shot_size": "medium-wide to wide shot, full body or knee-up",
"camera_angle": "eye-level or slightly low, not portrait lens close-up",
"character_position": "off-center on lower third or side third",
"environment_ratio": "at least 60% of the image is road, mist, sky, and surrounding space",
"directionality": "road line leads away from camera, character walking along it",
"gaze": "looking toward the road ahead, no direct camera gaze"
},
"style": {
"image_type": "photorealistic cinematic still",
"lens": "35mm or 50mm road-movie framing, natural perspective",
"lighting": "soft cold dawn light, low contrast, realistic shadows",
"color_grading": "muted blue-gray with slight warm skin undertone"
},
"constraints": {
"must_keep": [
"same character system as identity_ref",
"same wardrobe system as wardrobe_ref",
"body in motion, not posing",
"environment dominates the frame",
"road depth and walking direction are clear"
],
"avoid": [
"centered front-facing portrait",
"direct eye contact",
"heroic poster stance",
"fashion photo",
"clean new clothing",
"overly dramatic rainstorm",
"readable text, logo, watermark"
]
},
"failure_guard": "If the model over-prioritizes face identity and produces a portrait, reduce identity_ref weight and strengthen pose_ref + environment_ratio in the next prompt."
}
```
## T04 Advisor: Low-Angle Muddy Boots Detail
```json
{
"type": "cinematic MV detail shot / tactile continuity shot",
"goal": "Generate a vertical detail still where the character's struggle is carried by boots, mud, coat hem, and movement rather than face identity.",
"reference_strategy": {
"primary_ref": "wardrobe_ref or boots_ref",
"secondary_ref": "pose/action reference for stepping through wet mud",
"identity_ref": "not needed as primary; use only if the image tool supports low-weight reference roles"
},
"subject": {
"main": "muddy travel boots stepping into wet mud on a cold road",
"supporting_details": [
"dark long coat hem partially visible",
"old backpack strap or swinging shadow may appear at frame edge",
"mud splashes and wet gravel carry the sense of effort"
],
"face_visibility": "no face required"
},
"composition": {
"aspect_ratio": "vertical 9:16",
"camera": "very low angle near ground, close to boots",
"shot_size": "extreme low close-up with enough surrounding road texture",
"motion": "one boot compressing mud, the other lifting forward",
"depth": "road surface recedes into soft misty background"
},
"style": {
"image_type": "photorealistic cinematic road-movie detail",
"lighting": "cold natural dawn light, wet surface reflections",
"texture": "mud, water, scuffed boot leather, coat fabric edge",
"color_grading": "muted earth brown, wet black, cold blue-gray highlights"
},
"constraints": {
"must_keep": [
"boots and mud are the emotional subject",
"shot is not a portrait",
"same wardrobe language as the traveler system",
"tactile realism: mud has weight, water has reflections"
],
"avoid": [
"showing a face",
"clean boots",
"generic fashion footwear ad",
"fantasy heroic lighting",
"excessive splash that feels staged",
"readable text, logo, watermark"
]
},
"usage_note": "This shot should use wardrobe_ref / boots_ref as the main anchor. Overusing identity_ref is a known failure path."
}
```
## T05 Advisor: High-Density Explainer Slide Visual
```json
{
"type": "high-density explainer slide background / visual system",
"goal": "Generate a clean training-slide visual explaining staged visual anchors in AI image production. The generated image should provide structure and icons; final readable text should be added by slide tooling, not by the image model.",
"topic": "why AI image production needs staged visual anchors",
"style": {
"format": "clean explainer slide / ponchi-e inspired diagram",
"blend": "training slide clarity + soft operational illustration",
"color_palette": "warm off-white background, deep gray lines, muted red accent, small blue-gray highlights",
"information_density": "medium-high but readable"
},
"layout": {
"aspect_ratio": "16:9",
"title_safe_area": "top band left mostly empty for real slide title added later",
"centerpiece": "a horizontal workflow spine with five visual stations",
"sections": [
{
"id": "1",
"visual_role": "identity anchor",
"image": "small portrait-card icon with face silhouette and glasses marker, no readable text"
},
{
"id": "2",
"visual_role": "wardrobe anchor",
"image": "full-body outfit card icon with coat, backpack, boots"
},
{
"id": "3",
"visual_role": "pose / composition anchor",
"image": "side-walking pose frame with road perspective"
},
{
"id": "4",
"visual_role": "prompt rendering",
"image": "structured prompt card with abstract lines, not readable text"
},
{
"id": "5",
"visual_role": "review and rerun",
"image": "comparison/checklist icon and circular arrow"
}
],
"connector_style": "thin arrows between sections, light grid alignment, generous margins"
},
"constraints": {
"must_keep": [
"clear left-to-right process structure",
"visual hierarchy supports later overlay text",
"no dense generated text",
"icons are consistent in line weight and color",
"the diagram implies staged anchors before final image generation"
],
"avoid": [
"tiny unreadable paragraphs",
"random AI robot imagery",
"too many colors",
"crowded margins",
"fake UI text, logo, watermark"
]
},
"post_use_note": "After image generation, add real Chinese labels in slide/page tooling. Do not rely on the image model for final readable text."
}
```

View File

@ -0,0 +1,23 @@
# Direct Prompts
These prompts represent a competent direct GPT-style baseline without using `gpt-image-2` templates.
## T01 Direct: Character Identity Makeup Still
Create a realistic cinematic portrait of a 50-year-old East Asian male traveler. He has black rectangular glasses, short messy dark hair, light stubble, tired but steady eyes, and a quiet resilient expression. He wears a dark long coat with an old backpack strap visible. The mood is restrained, road-movie style, natural skin texture, soft overcast light, neutral background, no text, no logo, vertical portrait.
## T02 Direct: Wardrobe / Body Fullbody Anchor
Create a full-body reference image of the same 50-year-old East Asian male traveler. He wears a dark long coat, old backpack, worn trousers, and muddy boots. Show his body shape and outfit clearly from head to toe. The scene should be simple and neutral so the clothing can be reused as a reference. Realistic cinematic look, no text, no logo.
## T03 Direct: MV Side-Walking Road Shot
Using the traveler reference, create a vertical 9:16 cinematic MV still of him walking along a cold road in early morning. He is tired but still moving forward, wearing the same dark long coat, backpack, glasses, and muddy boots. The camera sees him from the side or three-quarter angle, not a front portrait. The environment should be wide and misty, with the road leading into the distance. No readable text.
## T04 Direct: Low-Angle Muddy Boots Detail
Create a vertical 9:16 cinematic close-up of the traveler's muddy boots stepping through wet mud on a road. Low angle near the ground, coat hem visible, rainwater and mud splashing, tired road-movie feeling. It should feel like the same traveler but without showing his face. Realistic, tactile, no text, no logo.
## T05 Direct: High-Density Explainer Slide Visual
Create a clean high-density explainer slide image about why AI image production needs staged visual anchors. Show a process from character identity to wardrobe, pose, scene, prompt, review, and rerun. Use simple icons and a clear flow, warm neutral colors, professional training style, no tiny unreadable text.

View File

@ -0,0 +1,13 @@
# Text-To-Image / Image-To-Image Execution Boundary Investigation
## Purpose
This investigation records how Video Workbench should distinguish text-to-image and image-to-image work after GPT V2 stops producing final image prompts and Codex becomes the local prompt owner.
## Scope
This is a workflow and responsibility investigation. It does not generate images and does not claim final image quality.
## Files
- `文生图与图生图执行边界调研.md`: local workflow findings and recommended rules.

View File

@ -0,0 +1,226 @@
# 文生图与图生图执行边界调研
```yaml
status: investigation
date: 2026-06-23
scope:
- text-to-image
- image-to-image
- video-workbench local execution workflow
non_goals:
- 不直接生图
- 不验证最终图片质量
- 不设计视频生成或剪辑流程
```
## 一、结论
在 GPT V2 改造后,文生图和图生图都属于 Codex / video-workbench 的阶段6以后执行层能力。
GPT V2 只提供:
- 视觉目标;
- 画面功能;
- 页面 / 镜头功能;
- 人物、场景、风格、模板、图示系统;
- 参考图需求;
- 验收关注点。
Codex 负责判断某个资产应走文生图还是图生图并负责最终提示词、试跑、review、失败归因和版本落盘。
核心规则:
> 文生图用于从文字规格生成初始资产;图生图用于在已有参考资产上保持、变体、修正或扩展。
## 二、文生图适用场景
文生图适合没有强参考图依赖、可以通过文字规格清楚定义的资产。
典型场景:
- 科普视频的概念隐喻图;
- 培训 PPT 的概念页背景;
- 客户方案 PPT 的商务图示背景;
- 信息图或流程图的初始视觉方向;
- `visual-system/` 的第一轮风格试跑;
- `slides/sNN/` 的第一版页面 / 镜头资产。
输入来源:
- GPT V2 阶段4通用表达与视觉系统
- GPT V2 阶段5页面 / 分镜 / 内容骨架;
- `execution-plan.md` 中的当前批次策略;
- `visual-system/visual-system.md` 中的当前接受版本;
- 单元级 `sNN-unit-spec.md``sNN-visual-brief.md`
输出文件通常是:
```text
slides/sNN/sNN-v1-prompt.md
slides/sNN/sNN-v1-image.png
slides/sNN/sNN-v1-review.md
```
或在视觉系统试跑阶段:
```text
visual-system/iterations/<round-id>-prompt.md
visual-system/iterations/<round-id>-image.png
visual-system/iterations/<round-id>-review.md
```
## 三、图生图适用场景
图生图适合已经有可用参考资产,并且新图需要保留某些视觉锚点时使用。
典型场景:
- 人物身份、服装、姿态、表情需要保持一致;
- PPT 模板已经接受,需要生成同一体系下的其他页面背景;
- 科普视频已经固定母题,需要生成后续镜头的同风格变体;
- 某张图片构图基本正确,只需要修改局部问题;
- 需要把外部平台生成的可用图转成项目统一风格;
- 需要在不破坏核心构图的情况下修正文字、图标、密度、光线或主体位置。
图生图的输入不应直接来自 GPT V2。它应来自项目内已经接受或待迭代的资产
```text
visual-system/refs/
visual-system/iterations/
slides/sNN/sNN-vN-image.png
```
图生图提示词必须显式拆分:
- must_preserve必须保持什么
- must_change必须修改什么
- can_change可以自由变化什么
- must_avoid必须避免什么
- reference_role参考图在本轮中的作用
- acceptance_criteria本轮通过标准。
输出文件仍按单元版本命名:
```text
slides/sNN/sNN-v2-prompt.md
slides/sNN/sNN-v2-image.png
slides/sNN/sNN-v2-review.md
```
## 四、和 `visual-system/` 的关系
`visual-system/` 是文生图和图生图的共同上游。
推荐顺序:
```text
GPT V2 阶段4
→ Codex 提炼 visual-system materialization targets
→ 文生图生成第一轮公共风格 / 模板 / 角色 / 场景参考
→ review
→ 接受的资产进入 visual-system 当前接受版本或 refs
→ 图生图用于保持一致性、扩展变体或修正问题
```
不要把图生图当成默认起点。没有稳定参考图时,图生图容易放大错误锚点。
也不要把文生图当成全流程唯一手段。项目一旦有已接受视觉系统,后续需要一致性的资产应优先考虑图生图或参考图约束。
## 五、和 `execution-plan.md` 的关系
`execution-plan.md` 应记录当前批次使用文生图还是图生图。
建议记录字段:
```md
## Current Round
- round:
- units_or_assets:
- generation_mode: text-to-image | image-to-image | mixed
- reference_assets:
- prompts_to_generate:
- images_to_generate:
- review_focus:
- next_action:
```
对于小批次试错,`execution-plan.md` 应说明本轮为什么选择这些单元:
- 代表不同页面类型;
- 覆盖高风险镜头;
- 检查人物一致性;
- 检查 PPT 模板复用;
- 检查文字 / 图表承载策略;
- 检查视觉母题是否能扩展。
## 六、和 `slides/slides.md` 的关系
`slides/slides.md` 只记录单元事实,不替代执行策略。
建议在表格中记录生成模式:
```md
| unit | batch | mode | prompt | image | review | accepted | notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| s01 | batch-01 | text-to-image | v1 | v1 | pass | yes | establishes opening style |
| s05 | batch-01 | image-to-image | v2 | v2 | revise | no | preserved style but composition too dense |
```
## 七、文字、公式、图表承载策略
不再使用全局 `no readable text` 规则。
Codex 在执行层判断信息由哪里承载:
- PPT 层;
- 页面 / 网页层;
- 图片层;
- 后期编辑层;
- 图标、图示或抽象符号;
- 其他工具。
判断依据是媒介目标,而不是固定禁令:
- 培训 PPT、科普 PPT、公式讲解、流程图、框架图可能需要文字、标签、公式或节点。
- 科普视频的背景图、隐喻图、氛围图通常不应让图像模型生成正文。
- MV / 剧情图通常更重视人物、场景、光线和情绪,不应塞入解释性文字。
## 八、失败归因
文生图常见失败:
- 隐喻漂移;
- 构图过散;
- 页面留白不足;
- 假文字或伪图表;
- 风格和项目公共系统不一致;
- 视觉资产像海报,不像可讲解页面组件。
图生图常见失败:
- 参考图锚点过强,改不动;
- 参考图锚点过弱,一致性丢失;
- 人物身份漂移;
- 模板被破坏;
- 局部修改造成整体构图退化;
- 版本之间差异不可控。
这些失败应记录到:
```text
visual-system/visual-system.md
slides/sNN/sNN-vN-review.md
```
## 九、当前采用规则
1. Codex 是最终图像提示词 owner。
2. GPT V2 不输出最终文生图或图生图提示词。
3. 文生图用于初始资产生成和低参考依赖资产。
4. 图生图用于参考资产已经存在后的保持、变体、修正和扩展。
5. `visual-system/` 先物化,单元资产再小批次推进。
6. `execution-plan.md` 记录每轮采用文生图、图生图或 mixed。
7. `slides/slides.md` 记录每个单元的实际生成模式和版本状态。
8. 单元资产使用 `sNN-vN-type.ext` 命名。
9. 是否让图片承载文字、公式、标签或图表,由执行层按媒介目标判断。
10. 本调研不证明最终图片质量,只固化本地执行边界。

View File

@ -0,0 +1,69 @@
# S14 Reference-Capable Generation Investigation
```yaml
status: user_decision_recorded
date: 2026-06-24
project: projects/2026-06-23-在路上
scope:
- image-reference generation
- identity consistency
- s14 half-profile shot
non_goals:
- no text-to-image baseline
- no broad shot production
- no API/Garden workflow
```
## Purpose
This investigation tests whether the current usable image-generation path can truly use character image references for identity-critical scene generation.
The test uses `S-14` because it is a high-risk half-profile identity shot. It compares two reference strategies with the same scene prompt:
| Arm | Reference input | Purpose |
| --- | --- | --- |
| A | `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-codex-posture-test.png` | Test whether the full character anchor board can carry overall identity, clothing, posture, and props into a scene. |
| B | `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-side-reference-crop-tight.png` | Test whether the side identity crop better preserves half-profile face, glasses, hair, beard, and age. |
## Files
- `s14-reference-test-plan.md`: test design, evidence standard, and review rubric.
- `prompts/s14-anchor-board-reference-prompt.md`: Arm A prompt.
- `prompts/s14-side-crop-reference-prompt.md`: Arm B prompt.
- `generation-log.md`: actual execution trace and reference-attachment evidence.
- `outputs/`: generated candidates copied into the workspace.
- `reviews/`: local review files and user decision conclusion.
## Current Boundary
The current `gpt-image-2` mode check returns `B-or-C` with no Garden API key. This investigation therefore tests the host built-in image-generation path, not Garden CLI/API generation.
For this investigation, a generation is considered reference-capable only if an actual image is made visible to the generation context before the call and the prompt explicitly assigns that image a reference role. A prompt that merely names a local file path is recorded as prompt-only and does not pass the reference-capability test.
## Current Result
Two candidates were generated and copied into `outputs/`:
```text
outputs/s14-anchor-board-reference-v1.png
outputs/s14-side-crop-reference-v1.png
```
Codex conclusion:
```text
reviews/summary-and-rule-implications.md
```
User decision has been recorded in:
```text
reviews/summary-and-rule-implications.md
```
The global Video Workbench rule was promoted into:
```text
AGENTS.md
VIDEO_WORKBENCH.md
```

View File

@ -0,0 +1,84 @@
# S14 Reference-Capable Generation Log
## Status
- Document status: complete, awaiting user review.
- Test date: 2026-06-24.
- Mode: `gpt-image-2` Skill `B-or-C`; host built-in image generation path tested.
- Garden/API path: not used; no local API key.
## Setup
Mode check command:
```powershell
node C:\Users\wangq\.agents\skills\gpt-image-2\scripts\check-mode.js --json
```
Mode check result:
```json
{
"mode": "B-or-C",
"recommendation": "host-or-advisor",
"garden_mode_enabled": false,
"has_api_key": false,
"base_url": "https://api.openai.com/v1",
"model": "gpt-image-2",
"env_flag_value": "(unset)"
}
```
## Execution Arms
### Arm A: Master Character Anchor Board
- Prompt file: `prompts/s14-anchor-board-reference-prompt.md`
- Input image role: character master anchor / identity, outfit, prop, posture reference.
- Input image path: `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-codex-posture-test.png`
- Output path: `outputs/s14-anchor-board-reference-v1.png`
- Host default output: `C:\Users\wangq\.codex\generated_images\019ef6bb-9965-7a00-a22e-7926700913e2\ig_0a8dfaa1541a868d016a3b163c6b7881919d3c842501d551e9.png`
- Execution status: completed.
- Reference capability evidence:
- the local reference image was loaded with `view_image` before generation;
- the `image_gen` prompt explicitly named the visible image as `Image 1`;
- the prompt defined `Image 1` as identity / outfit / posture / prop reference and not an edit target;
- the resulting image visibly preserved black rectangular glasses, dark messy hair, fuller beard, dark long coat, and backpack from the reference.
- Evidence limitation:
- the built-in `image_gen` tool schema does not expose an explicit file-path parameter;
- this validates host reference-by-visible-context behavior, not Garden/API multipart image upload.
- File metadata:
- width: `1672`
- height: `941`
- pixel format: `Format24bppRgb`
- bytes: `1905717`
### Arm B: Side Identity Crop
- Prompt file: `prompts/s14-side-crop-reference-prompt.md`
- Input image role: side-face identity reference.
- Input image path: `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-side-reference-crop-tight.png`
- Output path: `outputs/s14-side-crop-reference-v1.png`
- Host default output: `C:\Users\wangq\.codex\generated_images\019ef6bb-9965-7a00-a22e-7926700913e2\ig_05aaf64563018c7a016a3b16a6252881919597b10c4d9c880a.png`
- Execution status: completed.
- Reference capability evidence:
- the local reference image was loaded with `view_image` before generation;
- the `image_gen` prompt explicitly named the visible image as `Image 1`;
- the prompt defined `Image 1` as side-face identity reference and not an edit target;
- the resulting image visibly preserved side profile, black rectangular glasses, dark messy hair, fuller beard, long coat, and backpack from the reference.
- Evidence limitation:
- the built-in `image_gen` tool schema does not expose an explicit file-path parameter;
- this validates host reference-by-visible-context behavior, not Garden/API multipart image upload.
- File metadata:
- width: `1672`
- height: `941`
- pixel format: `Format24bppRgb`
- bytes: `2007496`
## Evidence Rule
The generated image is not enough by itself. This log must record whether the reference image was actually visible to the generation path. If the path only accepted prompt text, the generated candidate is marked prompt-only and cannot prove reference-capable generation.
## External Vision Analysis
An attempted external image-analysis call was rejected by the runtime safety layer because it would send workspace images to an unverified external service. This investigation therefore uses local visual inspection and local file metadata only.

View File

@ -0,0 +1,41 @@
watched_paths:
- "AGENTS.md"
- "VIDEO_WORKBENCH.md"
- "investigations/README.md"
- "investigations/2026-06-24-s14-reference-capable-generation/README.md"
- "investigations/2026-06-24-s14-reference-capable-generation/generation-log.md"
- "investigations/2026-06-24-s14-reference-capable-generation/s14-reference-test-plan.md"
- "investigations/2026-06-24-s14-reference-capable-generation/prompts/*.md"
- "investigations/2026-06-24-s14-reference-capable-generation/reviews/*.md"
status_fields:
- status
- lifecycle
forbidden_status_values:
- stable
- production-ready
- released
warning_status_values:
- accepted
- final
- complete
required_evidence_markers:
- User decision
- user decision
- user-approved
- 用户决策
approved_phrases:
- User-Approved
- user-approved
- owner-approved
- CCRA-approved
forbidden_phrases:
- production-ready
- released
allowed_contexts:
- "not accepted"
- "not the normal path"
- "not establish"
- "Do not describe"
- "no API"
- "no text-to-image"
- "no broad shot"

View File

@ -0,0 +1,35 @@
{
"scan_root": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench",
"config_path": "C:\\Users\\wangq\\Documents\\Codex\\video-workbench\\investigations\\2026-06-24-s14-reference-capable-generation\\lifecycle-guard-config.yaml",
"files_scanned": [
"AGENTS.md",
"investigations/2026-06-24-s14-reference-capable-generation/generation-log.md",
"investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-anchor-board-reference-prompt.md",
"investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-side-crop-reference-prompt.md",
"investigations/2026-06-24-s14-reference-capable-generation/README.md",
"investigations/2026-06-24-s14-reference-capable-generation/reviews/comparison-and-user-review.md",
"investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-anchor-board-reference-review.md",
"investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-side-crop-reference-review.md",
"investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md",
"investigations/2026-06-24-s14-reference-capable-generation/s14-reference-test-plan.md",
"investigations/README.md",
"VIDEO_WORKBENCH.md"
],
"possible_overclaims": [],
"field_level_findings": [],
"phrase_level_findings": [],
"missing_evidence_markers": [],
"warnings": [],
"blocking_errors": [],
"observations": [],
"machine_readable_summary": {
"status": "PASS",
"files_scanned_count": 12,
"field_finding_count": 0,
"phrase_finding_count": 0,
"missing_evidence_count": 0,
"warning_count": 0,
"blocking_count": 0,
"observation_count": 0
}
}

View File

@ -0,0 +1,36 @@
# Lifecycle Status Guard Scan
## Summary
- Status: `PASS`
- Files scanned: 12
- Blocking findings: 0
- Warnings: 0
- Evidence-present observations: 0
## Blocking Findings
- None
## Warnings
- None
## Observations
- None
## Files Scanned
- `AGENTS.md`
- `investigations/2026-06-24-s14-reference-capable-generation/generation-log.md`
- `investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-anchor-board-reference-prompt.md`
- `investigations/2026-06-24-s14-reference-capable-generation/prompts/s14-side-crop-reference-prompt.md`
- `investigations/2026-06-24-s14-reference-capable-generation/README.md`
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/comparison-and-user-review.md`
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-anchor-board-reference-review.md`
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/s14-side-crop-reference-review.md`
- `investigations/2026-06-24-s14-reference-capable-generation/reviews/summary-and-rule-implications.md`
- `investigations/2026-06-24-s14-reference-capable-generation/s14-reference-test-plan.md`
- `investigations/README.md`
- `VIDEO_WORKBENCH.md`

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.8 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.9 MiB

View File

@ -0,0 +1,86 @@
# S14 Anchor Board Reference Prompt
## Status
- Document status: used for Arm A generation.
- Project: `在路上`.
- Shot: `S-14`.
- Research arm: A, master character anchor board reference.
- Generation goal: test whether the full character anchor board can carry identity, outfit, prop, and posture cues into the `S-14` half-profile scene.
- This is not a text-to-image baseline.
## Reference Inputs
Input image:
```text
projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-codex-posture-test.png
```
Reference role:
- character master anchor;
- identity / age / glasses / hair / beard direction;
- outfit, coat, backpack, and posture reference;
- not an edit target;
- do not copy the board layout, labels, gray background, or multiple figure views.
## Rendered Prompt
Use case: photorealistic-natural
Asset type: `S-14` reference-capable generation test for the `在路上` MV.
Input images:
- Image 1: master character anchor board. Use it only as the identity, outfit, posture, coat, backpack, glasses, hair, and beard reference for the traveler. Do not copy the board layout, gray background, labels, multiple-view sheet format, or character-sheet composition.
Primary request:
Create one 16:9 horizontal realistic cinematic documentary still for `S-14` of the `在路上` MV. This is a brief half-profile confirmation shot in the city-pressure section. The output must use Image 1 as the character reference. The result should look like a new scene still, not an edited character board and not a portrait test.
Scene/backdrop:
A cold urban edge in shadow after the steel-concrete canyon. Wet gray concrete, bridge shadow, steel structure, damp retaining wall, worn rail, puddles, and cold city-edge air. The setting is utilitarian and physically real, not a clean commercial city center.
Subject:
A 50-year-old male road traveler, based on Image 1. He appears in half-body or upper-body half-profile, turned slightly away from camera, not direct front-facing. Preserve the key identity cues from Image 1: black rectangular glasses, dark somewhat longer slightly messy hair, fuller realistic beard / stubble, weathered middle-aged face, tired but dignified expression, dark gray / dark khaki / coal-black long road-worn coat, dark inner layer, old practical backpack strap visible.
Composition/framing:
16:9 horizontal frame. The traveler is side-positioned or off-center and occupies about one third of the frame or less. The cold urban edge must remain visible and emotionally important. Do not crop into a tight beauty portrait. The shot should feel like the camera briefly catches him in the city shadow after pressure has made him small.
Lighting/mood:
Cold gray daylight in bridge shadow, slight side light on part of the face, wet ground reflection, low saturation. The mood is tired, awake, dignified, and still moving. No glamour portrait lighting, no heroic rim light, no warm studio lighting.
Style/medium:
Photorealistic cinematic documentary road-film still. Real skin texture, natural weathering, restrained poetic realism, low-saturation cold gray / concrete gray / dark khaki / coal-black palette.
Must preserve from Image 1:
- same middle-aged traveler identity direction;
- black rectangular glasses;
- dark slightly messy longer hair;
- fuller beard / stubble;
- weathered face, tired but not defeated;
- dark long road-worn coat;
- old backpack strap or visible backpack clue;
- capable upright posture, not collapsed.
Must change from Image 1:
- replace the character-board layout with a real city-edge scene;
- show only one traveler, not a sheet of multiple views;
- remove all labels, board background, and reference-sheet layout;
- make the image a cinematic MV still.
Avoid:
No direct front-facing portrait, no professional portrait, no fashion editorial, no handsome movie-star styling, no hero poster, no glamour lighting, no young man, no clean-shaven face, no round glasses, no missing glasses, no collapsed posture, no homeless stereotype, no drunk stereotype, no cyberpunk, no neon, no futuristic UI, no code, no readable text, no logo, no watermark.
Acceptance behavior:
The viewer should first read a cold city-edge pause and then recognize the same road-worn traveler from Image 1. This should answer: "疲惫的人,你醒了吗" without turning the MV into a portrait MV.

View File

@ -0,0 +1,84 @@
# S14 Side Crop Reference Prompt
## Status
- Document status: used for Arm B generation.
- Project: `在路上`.
- Shot: `S-14`.
- Research arm: B, side identity crop reference.
- Generation goal: test whether the side identity crop better preserves half-profile identity traits for `S-14`.
- This is not a text-to-image baseline.
## Reference Inputs
Input image:
```text
projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-side-reference-crop-tight.png
```
Reference role:
- side-face identity reference;
- preserve black rectangular glasses, hair profile, beard/stubble, age impression, side-face structure, and coat collar;
- not an edit target;
- do not copy the crop background or tight crop framing exactly.
## Rendered Prompt
Use case: photorealistic-natural
Asset type: `S-14` reference-capable generation test for the `在路上` MV.
Input images:
- Image 1: side-face identity crop. Use it only as the half-profile identity reference for the traveler: face direction, black rectangular glasses, hair profile, beard / stubble, age, side-face structure, and coat collar. Do not copy the crop framing, source background, or reference-image lighting exactly.
Primary request:
Create one 16:9 horizontal realistic cinematic documentary still for `S-14` of the `在路上` MV. This is a brief half-profile confirmation shot in the city-pressure section. The output must use Image 1 as the side-face identity reference. The result should look like a new scene still, not a portrait remake and not a cropped-reference enlargement.
Scene/backdrop:
A cold urban edge in shadow after the steel-concrete canyon. Wet gray concrete, bridge shadow, steel structure, damp retaining wall, worn rail, puddles, and cold city-edge air. The setting is utilitarian and physically real, not a clean commercial city center.
Subject:
A 50-year-old male road traveler, based on Image 1. He appears in half-body or upper-body half-profile, turned slightly away from camera, not direct front-facing. Preserve the key side-identity cues from Image 1: black rectangular glasses, dark somewhat longer slightly messy hair, fuller realistic beard / stubble, weathered middle-aged face, tired but dignified expression, dark gray / dark khaki / coal-black long road-worn coat collar, dark inner layer, old practical backpack strap visible.
Composition/framing:
16:9 horizontal frame. The traveler is side-positioned or off-center and occupies about one third of the frame or less. Keep enough cold city-edge background to avoid a portrait. The image should feel like the camera briefly catches him in the city shadow after pressure has made him small.
Lighting/mood:
Cold gray daylight in bridge shadow, slight side light on part of the face, wet ground reflection, low saturation. The mood is tired, awake, dignified, and still moving. No glamour portrait lighting, no heroic rim light, no warm studio lighting.
Style/medium:
Photorealistic cinematic documentary road-film still. Real skin texture, natural weathering, restrained poetic realism, low-saturation cold gray / concrete gray / dark khaki / coal-black palette.
Must preserve from Image 1:
- same side-face identity direction;
- black rectangular glasses;
- dark slightly messy longer hair profile;
- fuller beard / stubble;
- weathered middle-aged face;
- tired but dignified expression;
- dark coat collar and restrained road-worn clothing direction.
Must change from Image 1:
- place the traveler into a real city-edge MV scene;
- expand to a 16:9 scene while keeping the person below portrait dominance;
- include backpack strap or practical road-traveler clothing context;
- do not copy the crop framing or background.
Avoid:
No direct front-facing portrait, no professional portrait, no fashion editorial, no handsome movie-star styling, no hero poster, no glamour lighting, no young man, no clean-shaven face, no round glasses, no missing glasses, no collapsed posture, no homeless stereotype, no drunk stereotype, no cyberpunk, no neon, no futuristic UI, no code, no readable text, no logo, no watermark.
Acceptance behavior:
The viewer should first read a cold city-edge pause and then recognize the same road-worn traveler from Image 1. This should answer: "疲惫的人,你醒了吗" without turning the MV into a portrait MV.

View File

@ -0,0 +1,55 @@
# S14 Reference Comparison And User Review
## Status
- Document status: user decision recorded.
- Codex local comparison: complete.
- User decision: recorded in `summary-and-rule-implications.md`.
## Outputs For Review
| Arm | Output | Reference |
| --- | --- | --- |
| A | `../outputs/s14-anchor-board-reference-v1.png` | master character anchor board |
| B | `../outputs/s14-side-crop-reference-v1.png` | side identity crop |
## Codex Comparison
| Dimension | Arm A: master board | Arm B: side crop |
| --- | --- | --- |
| Reference evidence | Pass via visible image context | Pass via visible image context |
| Identity preservation | Strong overall identity and outfit preservation | Stronger side-face identity preservation |
| Glasses / hair / beard | Preserved | Preserved more tightly in side profile |
| Coat / backpack | Very strong | Strong |
| S-14 half-profile function | Good, but a little more three-quarter | Better match |
| Environment-led MV feel | Slightly better scene balance | Slightly more figure-dominant |
| Main risk | Less precise side-face control | Portrait-size pull from crop |
## Codex Ranking
For `S-14` specifically:
1. Preferred primary reference: side identity crop.
2. Useful supporting reference: master character anchor board, especially if the tool path supports multiple reference images.
If only one reference can be used for `S-14`, Codex recommends the side identity crop.
If multiple references can be used, Codex recommends:
```text
Primary: character-anchor-v2-side-reference-crop-tight.png
Secondary: character-anchor-v2-codex-posture-test.png
```
The side crop should control face / glasses / hair / beard / age. The master board should control coat / backpack / posture / overall character continuity.
## User Decision
The user concluded:
1. The successful channel is `gpt-image-2` Advisor prompt generation plus loading the real reference image into context before host `image_gen`.
2. This successful channel should be used now and in future; API/Garden generation should not be the default path.
3. Both the master anchor board and crop reference preserved strong character consistency.
4. Near shots should prioritize crop references; distant shots should prioritize the anchor board.
5. For `在路上`, because most shots are landscape-led, aerial, or distant and only need character consistency, crops derived from the accepted anchor board are sufficient.
6. For future projects with high identity requirements and many close shots, higher-resolution crop references may be generated through image-to-image from the accepted anchor board before production.

View File

@ -0,0 +1,65 @@
# S14 Anchor Board Reference Review
## Status
- Document status: Codex local review.
- Research arm: A.
- Reference input: `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-codex-posture-test.png`.
- Generated image: `../outputs/s14-anchor-board-reference-v1.png`.
- Review result: usable candidate for user review; not a final project shot.
## Reference Path Evidence
This run is not prompt-only:
- the master character anchor image was loaded with `view_image` before generation;
- the generation prompt referred to the loaded image as `Image 1`;
- the prompt assigned `Image 1` a character reference role;
- the output shows multiple visual traits from the reference.
Limitation:
- the built-in image tool does not expose a file-path upload argument in the visible tool schema;
- this proves reference-by-visible-context for the host path, not Garden/API explicit image upload.
## Local Visual Inspection
Visible preserved identity cues:
- black rectangular glasses preserved;
- dark slightly messy longer hair preserved;
- fuller beard / stubble preserved;
- weathered middle-aged face preserved;
- dark long road-worn coat preserved;
- old backpack preserved and visible;
- traveler reads tired but dignified, not collapsed.
Shot-function fit:
- cold city-edge environment is present;
- wet concrete, overpass shadow, rail, and waterway create system-pressure space;
- person is off-center enough for a scene still rather than pure portrait;
- no obvious text, UI, neon, sci-fi, logo, or watermark.
Drift / watch points:
- the face is closer to a three-quarter view than a strict side profile;
- the person is visually strong, close to the upper size limit for an environment-led MV shot;
- the city background is good but slightly cinematic-clean compared with the roughest project references.
## Rubric
| Criterion | Assessment | Notes |
| --- | --- | --- |
| Actual reference made available | pass with host-context caveat | `view_image` before generation plus explicit `Image 1` prompt role. |
| Same traveler identity | pass | Strong preservation of glasses, hair, beard, coat, backpack. |
| Age and dignity | pass | Reads middle-aged and tired but not collapsed. |
| Half-profile S-14 function | mostly pass | It is closer to three-quarter half-profile than pure side. |
| Environment remains meaningful | pass | Urban edge is visible and not merely a portrait backdrop. |
| Avoids major drift | pass | No fashion, hero, cyber/UI, or glamour drift. |
## Codex Read
The master anchor board works surprisingly well as a general identity and outfit reference. It carries more complete character information than the side crop, especially coat, backpack, and overall road-worn presence.
For `S-14`, its weakness is precision: because the board contains multiple views and a front identity panel, the result leans toward a more readable three-quarter face rather than a strict side half-profile. This is acceptable for a trial image, but not the best primary reference if the shot needs controlled side-face identity.

View File

@ -0,0 +1,65 @@
# S14 Side Crop Reference Review
## Status
- Document status: Codex local review.
- Research arm: B.
- Reference input: `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-side-reference-crop-tight.png`.
- Generated image: `../outputs/s14-side-crop-reference-v1.png`.
- Review result: usable candidate for user review; not a final project shot.
## Reference Path Evidence
This run is not prompt-only:
- the side crop image was loaded with `view_image` before generation;
- the generation prompt referred to the loaded image as `Image 1`;
- the prompt assigned `Image 1` a side-face identity reference role;
- the output shows direct visual continuity with the reference side profile.
Limitation:
- the built-in image tool does not expose a file-path upload argument in the visible tool schema;
- this proves reference-by-visible-context for the host path, not Garden/API explicit image upload.
## Local Visual Inspection
Visible preserved identity cues:
- side profile is strongly preserved;
- black rectangular glasses preserved;
- dark messy longer hair silhouette preserved;
- fuller beard / stubble preserved;
- middle-aged face impression preserved;
- dark long coat and backpack preserved;
- body reads upright and capable.
Shot-function fit:
- cold underpass / wet concrete edge is present;
- background remains visible enough to read as a city-pressure scene;
- side profile matches the intended `S-14` half-profile function well;
- no obvious text, UI, neon, sci-fi, logo, or watermark.
Drift / watch points:
- the figure is large and visually dominant, near the upper limit for S-14;
- the crop-reference influence is strong, which helps identity but can pull the image toward portrait dominance;
- the scene is slightly darker and moodier than Arm A, which works for S-14 but should be checked against adjacent shots.
## Rubric
| Criterion | Assessment | Notes |
| --- | --- | --- |
| Actual reference made available | pass with host-context caveat | `view_image` before generation plus explicit `Image 1` prompt role. |
| Same traveler identity | pass | Strong preservation of side profile, glasses, hair, beard, coat, backpack. |
| Age and dignity | pass | Reads middle-aged and tired but not collapsed. |
| Half-profile S-14 function | pass | Better side-profile control than Arm A. |
| Environment remains meaningful | mostly pass | Background is present, though person dominates more. |
| Avoids major drift | pass | No fashion, hero, cyber/UI, or glamour drift. |
## Codex Read
The side crop is the better primary reference for `S-14`-type half-profile identity shots. It preserves the specific side-face structure and profile cues more tightly than the master board.
Its tradeoff is composition: because the input is a tight identity crop, the generated scene tends to keep the figure larger and more dominant. The prompt should keep a stronger scale constraint if this path is used for production.

View File

@ -0,0 +1,88 @@
# Summary And Rule Implications
## Status
- Document status: investigation conclusion with user decision recorded.
- Rule changes: promoted to `AGENTS.md` and `VIDEO_WORKBENCH.md`.
- User decision date: 2026-06-24.
## User Decision Conclusion
This investigation established the working Video Workbench success channel for image-reference generation:
1. Generate the prompt/spec with the `gpt-image-2` Skill Advisor workflow.
2. Load the real reference image into the conversation context before generation.
3. Use host `image_gen` with the loaded image assigned an explicit role such as `Image 1`.
This is the default channel for current and future Video Workbench image generation. API/Garden image generation is not the normal path.
Both reference strategies tested here worked:
- the full character anchor board preserved strong character consistency;
- the side crop also preserved strong character consistency;
- near / identity-heavy shots should prioritize crop references;
- distant / landscape-led shots should prioritize the accepted anchor board or project-approved distant reference.
For `在路上`, most shots are landscape, aerial, or distant. The project does not require high-fidelity portrait likeness in most frames; it primarily needs character consistency. The current crop set, which was derived from the accepted character anchor board and made transparent, is sufficient by default.
For future projects with higher identity requirements and many close shots, create higher-resolution crop references through image-to-image from the accepted anchor board before production.
## What This Investigation Proves
The host built-in image generation path can use an image made visible in the conversation context as a reference input for identity-sensitive generation.
This was not a pure text-to-image run:
- Arm A loaded the master anchor board before generation.
- Arm B loaded the side identity crop before generation.
- Both prompts explicitly assigned the loaded image as `Image 1`.
- Both outputs preserved concrete visual traits that were present in the loaded reference images: black rectangular glasses, dark messy hair, fuller beard / stubble, dark long coat, and backpack.
## Boundary
This investigation does not establish an API/Garden workflow, because:
- `gpt-image-2` Garden mode is not enabled;
- no `OPENAI_API_KEY` is present;
- the built-in `image_gen` tool schema exposes only a text prompt parameter.
The validated route should be named precisely:
```text
host built-in reference-by-visible-context
```
Do not describe the default workflow as:
```text
Garden image-to-image
explicit file-path upload
API multipart image edit
```
## Operating Rule
For Video Workbench use, the built-in route is the default for reference-capable generation if the prompt workflow records the evidence:
1. load the exact reference image into the conversation context before generation;
2. state the image's role in the prompt as `Image 1`, `Image 2`, etc.;
3. record the input file path, output file path, and evidence caveat in `generation-log.md` or per-shot prompt/review;
4. do not count a run as reference-capable if the prompt merely names a local path without loading the image.
Reference selection defaults:
| Shot type | Recommended primary reference |
| --- | --- |
| Near shot, face, half-profile, expression, identity-heavy frame | Matching crop reference first |
| Distant shot, landscape-led frame, aerial / wide scene, low identity burden | Accepted character anchor board or project-approved distant reference first |
| Medium action, back view, walking pose, prop continuity | Matching crop, transparent slice, or anchor board according to visible direction |
| High identity fidelity project with many close shots | Generate higher-resolution crop references through image-to-image from the accepted anchor board before production |
## Rule Promotion
Promoted to:
- `AGENTS.md`
- `VIDEO_WORKBENCH.md`
Project-specific registries may add narrower reference selection tables when a project needs them, but the global path and near/distant reference-choice defaults now live in the workspace rules.

View File

@ -0,0 +1,107 @@
# S14 Reference-Capable Generation Test Plan
## Status
- Document status: completed test plan.
- Test shot: `S-14`.
- Source shot folder: `projects/2026-06-23-在路上/slides/s14/`.
- Existing broad-run candidate: `projects/2026-06-23-在路上/slides/s14/s14-v1-image.png`.
- Existing candidate status: broad-run candidate only; not accepted; not used as a reference input.
## Research Question
Can the current image-generation path use actual character image references well enough for identity-critical half-profile shots?
Sub-questions:
1. Does a full character anchor board preserve the same traveler identity in a new scene?
2. Does a side identity crop preserve half-profile face traits better than the full board?
3. Does the resulting shot still function as `S-14`, not as a portrait or character test image?
4. What rule changes should be considered after the user reviews the two outputs?
## Method
Use the same `S-14` prompt core for both arms. Do not run a text-to-image baseline.
| Arm | Input image | Role | Output |
| --- | --- | --- | --- |
| A | `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-codex-posture-test.png` | identity / outfit / posture / prop reference; not edit target | `outputs/s14-anchor-board-reference-v1.png` |
| B | `projects/2026-06-23-在路上/visual-system/characters/character-anchor-v2-side-reference-crop-tight.png` | side-face identity reference; not edit target | `outputs/s14-side-crop-reference-v1.png` |
## Evidence Standard
A generation is counted as a real reference test only if:
- the image was loaded into the generation context before calling the image tool;
- the prompt includes an `Input images` section naming the image role;
- `generation-log.md` records the exact input file, output file, and execution path;
- the output is copied into this investigation's `outputs/` directory.
If the tool path accepts only plain text and cannot see the image, the result must be recorded as prompt-only and cannot prove reference capability.
## Skill Workflow
Mode check command:
```powershell
node C:\Users\wangq\.agents\skills\gpt-image-2\scripts\check-mode.js --json
```
Mode check result at setup:
```json
{
"mode": "B-or-C",
"recommendation": "host-or-advisor",
"garden_mode_enabled": false,
"has_api_key": false,
"base_url": "https://api.openai.com/v1",
"model": "gpt-image-2",
"env_flag_value": "(unset)"
}
```
Skill files read:
- `C:\Users\wangq\.agents\skills\gpt-image-2\SKILL.md`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\prompt-writing.md`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\scenes-and-illustrations\concept-scene.md`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\scenes-and-illustrations\minimalist-mood-scene.md`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\editing-workflows\portrait-local-edit.md`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\portraits-and-characters\professional-portrait.md`
Template adaptation:
- `concept-scene.md` supplies foreground / midground / background scene layering.
- `minimalist-mood-scene.md` supplies restraint and anti-spectacle discipline.
- `portrait-local-edit.md` supplies identity-preservation language for reference images.
- `professional-portrait.md` is used mainly as a negative boundary: this shot must not become a professional portrait.
## Project Sources
- `projects/2026-06-23-在路上/intake/阶段五-人物一致性单镜.md`
- `projects/2026-06-23-在路上/visual-system/visual-system.md`
- `projects/2026-06-23-在路上/visual-system/characters/character-reference-registry.md`
- `projects/2026-06-23-在路上/visual-system/characters/character-identity-lock.md`
- `projects/2026-06-23-在路上/visual-system/style/style-prompt-master.md`
- `projects/2026-06-23-在路上/slides/broad-generation-self-audit-v1.md`
## Review Rubric
Each output is checked on:
1. Reference-path evidence: was an actual image made available before generation?
2. Identity: does the traveler retain 50-year-old age, black rectangular glasses, dark messy hair, beard/stubble, and tired dignity?
3. Costume and props: dark long coat and backpack strap remain stable.
4. Shot function: brief half-profile confirmation inside city pressure, not a portrait.
5. Composition: 16:9 scene with cold urban edge background; person about one third of frame or less.
6. Drift: no fashion model, hero poster, homeless stereotype, celebrity portrait, glamour lighting, cyber/tech UI, readable text, logo, or watermark.
## Decision After Review
After the two generated images and Codex conclusion are reviewed by the user, decide whether to modify:
- `visual-system/characters/character-reference-registry.md`;
- `visual-system/style/style-prompt-master.md`;
- `VIDEO_WORKBENCH.md`;
- future `sNN-vN-prompt.md` reference-input rules.

View File

@ -0,0 +1,140 @@
# Thread Notification Wakeup Investigation
Date: 2026-06-24
## Status
- Status: Test 1 passed; workflow promotion pending production-shaped validation.
- Scope: Codex app thread notification / wakeup behavior for Video Workbench child-session orchestration.
- Not a stable workflow rule until accepted conclusions are promoted into `docs/workflows/`, `VIDEO_WORKBENCH.md`, or `AGENTS.md`.
## Problem
The current slide-task workflow uses parent-side waiting and polling:
```text
main session starts child session
-> main session sleeps
-> main session polls child session until completion or timeout
```
This keeps the parent session active for long child runs. The desired behavior is:
```text
main session starts child session
-> main session ends the current turn
-> child session completes work later
-> child session sends a callback to the parent thread
-> parent session wakes and consumes the child handoff
```
## User-Authorized Parent Thread Discovery
There is no known user-facing shell command for the user to obtain the current Codex thread id.
For this investigation, the user explicitly authorizes the parent session to discover the parent thread id through the Codex app thread list at runtime, with this precondition:
```text
The user guarantees only one active main Video Workbench session is running.
```
Discovery rule:
1. Query Codex app threads.
2. Select the thread with:
- `status: active`;
- `cwd: C:\Users\wangq\Documents\Codex\video-workbench`;
- title / preview matching the active notification-wakeup investigation.
3. Treat the result as a runtime observation, not as a stable external API.
Observed parent thread for Test 1:
```text
019ef999-07d2-7333-99b4-d5d2da040406
```
Observation caveat:
- The thread list may contain old idle or not-loaded sessions.
- The selection is considered safe only when the user-controlled precondition holds: one active main Video Workbench session.
## Test 1 Design
Goal:
```text
Prove whether a child Codex thread can wake the parent thread by sending a message to the observed parent thread id after a delay.
```
Carrier:
```text
Clean visible child Codex thread in the same local `video-workbench` project.
```
Steps:
1. Parent records this investigation design.
2. Parent creates one clean child thread.
3. Child waits for 2 minutes.
4. Child sends a callback message to the parent thread id using `send_message_to_thread`.
5. Child writes a local result file under this investigation directory.
6. Parent does not poll the child thread.
7. If the parent thread wakes from the child callback, the parent records the result report.
Success criteria:
- Parent receives a child callback without parent-side polling.
- Parent can continue from the callback and record a result report.
- Child result file exists and identifies the child thread, parent thread, callback time, and callback method.
Failure / inconclusive criteria:
- Child completes but parent is not activated.
- Child cannot access `send_message_to_thread`.
- Child cannot send to the parent thread id.
- Parent wakes only because of unrelated manual/user action.
## Test 1 Runtime Values
```text
parent_thread_id: 019ef999-07d2-7333-99b4-d5d2da040406
child_thread_id: 019ef9a5-5efc-7500-9a7d-4e7ec6920e84
parent_thread_observation_method: Codex app list_threads
workspace: C:\Users\wangq\Documents\Codex\video-workbench
delay: 2 minutes
parent_polling_allowed: no
```
Expected child result path:
```text
investigations/2026-06-24-thread-notification-wakeup/test-1-child-result.md
```
Expected parent report path if awakened:
```text
investigations/2026-06-24-thread-notification-wakeup/test-1-report.md
```
## Test 1 Result
Result:
```text
pass
```
Summary:
- The child slept 120 seconds.
- The child sent a callback with `send_message_to_thread`.
- The parent thread received the child callback without parent-side polling.
- Detailed report: `test-1-report.md`.
Promotion status:
```text
Do not promote into the production slide-task workflow until a production-shaped slide-package test confirms the same callback path.
```

View File

@ -0,0 +1,10 @@
# Test 1 Child Result
- status: slept 2 minutes and sent callback
- parent_thread_id: 019ef999-07d2-7333-99b4-d5d2da040406
- child_thread_id: 019ef9a5-5efc-7500-9a7d-4e7ec6920e84
- sleep duration: 120 seconds
- callback method: Codex app send_message_to_thread
- callback target: 019ef999-07d2-7333-99b4-d5d2da040406
- callback sent / failed: sent
- any tool limitation: send_message_to_thread was not initially exposed; tool_search exposed it successfully

View File

@ -0,0 +1,23 @@
# Test 1 Parent Dispatch
## Runtime Values
```text
parent_thread_id: 019ef999-07d2-7333-99b4-d5d2da040406
child_thread_id: 019ef9a5-5efc-7500-9a7d-4e7ec6920e84
workspace: C:\Users\wangq\Documents\Codex\video-workbench
delay: 2 minutes
parent_polling_allowed: no
```
## Dispatch Contract
The child thread must:
1. Sleep for 2 minutes after the formal start message.
2. Write `test-1-child-result.md`.
3. Send a callback to the parent thread using `send_message_to_thread`.
4. Report whether callback sending succeeded.
The parent thread must not inspect or poll the child thread after dispatch. If the parent wakes from the child callback, it may write `test-1-report.md`.

View File

@ -0,0 +1,84 @@
# Test 1 Report
Date: 2026-06-24
## Status
- Result: pass for the minimal callback wakeup test.
- Parent observed report time: 2026-06-24T20:44:15.6912187+08:00
- Parent polling used after dispatch: no.
## Parent-Side Observation
The parent session ended its dispatch turn after sending the formal start message to child thread:
```text
019ef9a5-5efc-7500-9a7d-4e7ec6920e84
```
The next input received by the parent thread was the child callback:
```text
Video Workbench wakeup Test 1 callback from child thread 019ef9a5-5efc-7500-9a7d-4e7ec6920e84.
If this message activated the parent thread without polling, record the result in investigations/2026-06-24-thread-notification-wakeup/test-1-report.md.
Child result path: investigations/2026-06-24-thread-notification-wakeup/test-1-child-result.md
Parent thread id: 019ef999-07d2-7333-99b4-d5d2da040406
```
This indicates the parent thread was activated by the child callback path, not by parent-side polling.
## Child-Side Evidence
Child result file:
```text
investigations/2026-06-24-thread-notification-wakeup/test-1-child-result.md
```
Recorded child result:
```text
status: slept 2 minutes and sent callback
parent_thread_id: 019ef999-07d2-7333-99b4-d5d2da040406
child_thread_id: 019ef9a5-5efc-7500-9a7d-4e7ec6920e84
sleep duration: 120 seconds
callback method: Codex app send_message_to_thread
callback target: 019ef999-07d2-7333-99b4-d5d2da040406
callback sent / failed: sent
any tool limitation: send_message_to_thread was not initially exposed; tool_search exposed it successfully
```
## Finding
For a minimal two-minute test, a clean visible child Codex thread can wake the parent thread by calling `send_message_to_thread` with the parent thread id.
The parent thread id can be obtained by the parent session at runtime through Codex app thread-list observation, under the user-controlled precondition that only one active main Video Workbench session is running.
## Limits
This test does not yet prove the full production slide workflow should replace polling immediately.
Remaining questions:
- whether the same callback behavior remains reliable after 30-60 minute child runs;
- whether callback delivery behaves the same when the child has heavy tool use, image generation, or internal SubAgents;
- whether a production child session should send the callback only after writing `child-session-handoff.md` and passing the completion gate;
- how to handle callback send failure without falling back to hidden parent polling;
- whether the parent should still keep a very long safety timeout outside normal workflow execution.
## Workflow Implication
Candidate replacement for routine parent polling:
```text
parent observes current parent_thread_id
-> parent creates clean child session
-> parent sends task packet containing parent_thread_id and callback contract
-> parent ends turn
-> child writes compact handoff after completion gate
-> child calls send_message_to_thread(parent_thread_id, callback)
-> parent wakes and reads compact handoff
```
Do not promote this into `docs/workflows/slide-task-orchestration.md` until at least one production-shaped child-session test confirms the callback after a real slide package.

24
investigations/README.md Normal file
View File

@ -0,0 +1,24 @@
# Investigations
This directory holds research reports, experiments, comparisons, and draft workflow proposals for Video Workbench.
Investigation files are not stable operating rules by themselves. Accepted conclusions must be promoted into `README.md`, `VIDEO_WORKBENCH.md`, `docs/`, or project templates before they become durable workflow rules.
## Current Records
```text
2026-06-23-gpt-image-2-advisor-prompt-quality/
2026-06-23-gpt-image-2-advisor-prompt-quality-v2-broader-use-cases/
2026-06-23-text-to-image-image-to-image-execution-boundary/
2026-06-24-s14-reference-capable-generation/
2026-06-24-thread-notification-wakeup/
```
Notes:
- The first prompt-quality investigation over-weighted character and MV identity scenarios. It is retained as historical evidence.
- The V2 prompt-quality investigation is the accepted basis for shifting final image prompt ownership to Codex.
- The text-to-image / image-to-image execution-boundary investigation records local workflow policy only. It does not validate final image quality.
- The S14 reference-capable generation investigation established the current default success channel: `gpt-image-2` Advisor prompt/spec, then load the real reference image into context, then generate with host `image_gen`. Its conclusions were promoted into `AGENTS.md` and `VIDEO_WORKBENCH.md`.
- The thread-notification wakeup investigation tests whether child sessions can wake the parent thread through a direct callback instead of parent-side polling. It is not yet promoted into the slide-task workflow.
- Any historical `makeup-still/` directory recommendation inside old investigation files is superseded by the current `visual-system/` rule.

View File

@ -0,0 +1,11 @@
# Archived Character Files
This directory stores historical and process files from the character anchor stage.
Files here are not default scene-generation references. Use the active registry instead:
```text
visual-system/characters/character-reference-registry.md
```
Archived files may be reopened only for audit, comparison, or a targeted character-anchor repair.

View File

@ -0,0 +1,203 @@
# Character Anchor Board V1
## Status
- Document status: pending review.
- Execution status: non-generation-ready draft; do not generate from this file.
- Compliance note: this draft was written before the repository rule requiring `gpt-image-2` Skill workflow for all project-bound image prompts. It must be rebuilt through the Skill, with mode/template/source records, before any image generation.
- Target: one 16:9 character anchor board for the traveler in `在路上`.
- Scope: main board only. Transparent character slices are a later step.
## Purpose
This board is a character consistency control sheet, not a finished MV shot, poster, portrait, or atmosphere image.
It must lock:
1. front / side / back body silhouette;
2. hair, stubble, age, and weathered facial state;
3. long coat, inner layer, old backpack, and old boots;
4. walking side and walking back posture;
5. the boundary between tired dignity and visual drift.
Core question:
> Later, when this person becomes small in a wide landscape shot, can we still recognize him as the same traveler?
## Page Spec
- Aspect ratio: 16:9 horizontal.
- Background: very light neutral gray-white or very light warm gray.
- Style: clean working character standard sheet, restrained documentary design.
- Lighting: soft neutral studio-like light, no dramatic scene lighting.
- Layout: one page with title area, character views, object breakdown, and short labels.
- Image role: execution reference, not promotional art.
## Board Layout
### Top Title Area
Title:
> 《在路上》人物锚点板 / Character Anchor Board
Subtitle:
> 路上行者角色设定板
One-line definition:
> 50 岁左右的路上行者;沧桑摇滚,温暖疲惫,孤独但坚定。
### Main View Area
Use a 3-column working-board layout:
1. left column: three-view core;
2. middle column: state views;
3. right column: clothing and prop breakdown.
Required visual cells:
| Cell | Content | Function |
| --- | --- | --- |
| A1 | front full body | age, body proportion, coat front, inner layer, overall temperament |
| A2 | side full body | side silhouette, jaw/stubble profile, coat fall, backpack volume |
| A3 | back full body | back-view recognition, rear hair shape, backpack, coat hem |
| B1 | half-body state | face age, hair, stubble, tired dignity |
| B2 | walking side | gait, coat movement, body weight, continuing-forward feeling |
| B3 | walking back | key MV silhouette for later wide/back shots |
| C1 | long coat / inner layer detail | color, length, worn texture, restrained shape |
| C2 | old backpack detail | practical old backpack, used but not broken |
| C3 | old boots detail | old walking boots, can carry mud, not fashion shoes |
### Bottom Rule Area
Keep the text short and functional.
Keywords:
- 50 岁左右
- 路上行者
- 沧桑摇滚
- 温暖疲惫
- 孤独但坚定
- 被生活和系统磨过,但精神没塌
Allowed:
- wind-worn feeling
- tiredness
- practical old clothing
- restrained ruggedness
- mud and use traces
Forbidden:
- homeless coding
- drunk coding
- fashion model styling
- heroic poster pose
- polished travel blogger image
- collapse, defeat, or visual pity
## Character Definition
The character is a 50-year-old male traveler.
He is not a celebrity, not a fashion model, not a homeless man, not a drunk figure, and not a victorious hero. He is a person worn by life and systems, but still moving.
### Appearance Anchors
- dark, slightly messy hair;
- visible stubble;
- weathered but warm middle-aged face;
- dark gray / dark khaki / coal-black long traveler's coat;
- dark restrained inner layer;
- old practical backpack;
- old walking boots;
- body capable of continuing forward, neither frail nor gym-styled.
### Temperament Anchors
- weathered rock feeling;
- warm but tired;
- lonely but steady;
- silent, not defeated;
- tired dignity rather than collapse.
## Main Image Prompt
Create a 16:9 horizontal character anchor board for a poetic road-documentary music video titled "在路上".
The page is a clean working character standard sheet on a very light neutral gray-white background. It shows the same 50-year-old male traveler in multiple consistent views, with short functional labels and thin annotation lines. The design is restrained, practical, and cinematic, but not decorative.
Character identity: a 50-year-old male traveler, weathered by life and systems, warm but tired, lonely but steady, silent and not defeated. Dark slightly messy hair, visible stubble, weathered middle-aged face, dark gray / dark khaki / coal-black long traveler's coat, dark inner layer, old practical backpack, old walking boots. The body should feel able to keep walking: neither frail nor athletic, neither stylish nor broken.
Layout: top title area with "《在路上》人物锚点板 / Character Anchor Board" and the short definition "50 岁左右的路上行者;沧桑摇滚,温暖疲惫,孤独但坚定。"
Main board content: three-view full-body core with front view, side view, and back view at consistent scale; state views with half-body state, walking side view, and walking back view; prop breakdowns for long coat and inner layer, old backpack, and old boots. Keep all views recognizable as the same person. Make the back view and walking back view especially clear because later MV shots will often show the traveler from behind or from far away.
Board style: clean restrained film pre-production character sheet, light gray-white background, soft neutral light, readable silhouettes, low-saturation clothing colors, fine annotation lines, short labels only. The board should help later image generation keep the character consistent in wide landscapes, city edge shots, muddy road shots, and night fire shots.
Emotional boundary: tired but dignified, worn but not ruined, lonely but still moving. The character should never become a portrait subject, heroic poster figure, fashion traveler, drunk man, or homeless visual stereotype.
## Negative Prompt / Exclusion Rules
Avoid:
- front-facing glamour portrait;
- heroic stance;
- arms-open inspirational pose;
- fashion editorial styling;
- travel blogger image;
- model-like grooming;
- luxury outdoor gear;
- cyberpunk, neon, sci-fi, UI, code, futuristic clothing;
- homeless stereotype;
- drunk stereotype;
- dirty collapse;
- exaggerated poverty;
- comic-book character sheet style;
- anime style;
- glossy game concept art;
- fantasy armor;
- cinematic poster lighting;
- dramatic landscape background;
- muddy road scene background;
- city background;
- campfire background;
- heavy gradient background;
- colorful magazine layout;
- text-heavy page.
## Suggested Generation Settings
These are generation guidance notes, not required tool commands.
- Format: 16:9 horizontal.
- Resolution target: high enough for text and small object labels to remain readable.
- Background: light gray-white, nearly flat.
- Character count: one character repeated across views, not multiple different people.
- Text density: low. Use short labels only.
- Priority: character consistency over beauty.
- Most important cells: front full body, side full body, back full body, walking back.
## Review Checklist
Use this checklist before accepting the board.
1. Do front, side, and back views clearly look like the same person?
2. Is the back view recognizable without relying on the face?
3. Does walking side / walking back feel real rather than posed?
4. Is tiredness balanced with dignity?
5. Are coat, backpack, and boots stable enough to guide later shots?
6. Does the board avoid homeless, drunk, fashion model, hero poster, and travel blogger drift?
7. When the character is mentally shrunk to a wide shot, do coat, backpack, boots, shoulder line, and gait still read as the same traveler?
8. Is the board useful as an execution reference rather than just a good-looking illustration?
## Pending User Review
If approved, the next step is to generate the first character anchor board attempt from this document.
Do not proceed to transparent slices, style anchor board, or five-shot tests until this document is accepted and the first board generation step is explicitly requested.

View File

@ -0,0 +1,309 @@
# Character Anchor Brief V1
## Status
- Document status: pending review.
- Execution status: brief only; do not generate images from this file.
- Source basis: primary character intake files plus approved trial plan.
- Next gated action after approval: create `character-anchor-prompt-v1.md` through the `gpt-image-2` Skill workflow.
## Purpose
This brief defines the project-specific character anchor requirements for `在路上`.
It is not a final image prompt. It is the execution source that the next Skill-based prompt document should use.
The character anchor must answer:
> When the traveler appears as a small side view, back view, or distant figure in later MV shots, can we still tell this is the same person?
## Source Files Actually Used
Primary sources:
- `intake/阶段四-人物锚点板策划说明.md`
- `intake/阶段四-人物锚点板页面结构建议稿.md`
- `intake/阶段四-人物锚点板文案标注稿.md`
Planning gate:
- `visual-system/characters/character-anchor-trial-plan.md`
Not used in this brief:
- User source photo: not read yet. It will be handled in the prompt stage as an identity reference if the file is readable and approved for use.
- `character-anchor-board-v1.md`: treated as a non-generation-ready draft, not as an authoritative source.
## Source Photo Role
The user source photo path is:
```text
C:\Users\wangq\Pictures\照片\photo.jpg
```
Role in later prompt work:
- identity reference;
- face direction and lived-person basis;
- age, facial structure, hair / stubble direction if visible;
- not an edit target;
- not a passport-photo style target;
- not a requirement to reproduce the exact original photo pose, lighting, background, or clothing.
Expected transformation:
> Use the source photo to keep a recognizable human basis, then translate the figure into the `在路上` traveler identity: weathered, restrained, road-worn, and usable across distant landscape-led shots.
The prompt stage must explicitly label this input as `identity reference`.
## Character Role In The MV
The traveler is not the visual protagonist in a portrait-MV sense.
He is a moving coordinate inside a larger world:
- world before face;
- road before pose;
- silhouette before expression;
- continuation before victory.
The character anchor must support wide shots, back shots, side shots, muddy-road shots, city-edge shots, and night-fire shots.
## Identity Definition
### Core Identity
- 50-year-old male traveler.
- Based on the user's self-image direction, but translated into a road-film character.
- Worn by life and systems, but still walking.
- Not a celebrity, fashion model, homeless figure, drunk figure, or hero-poster protagonist.
### Temperament
- weathered rock feeling;
- warm but tired;
- lonely but steady;
- silent, not defeated;
- tired but not broken;
- rugged but not collapsed;
- road-worn dignity.
### Body And Presence
- body should feel capable of continuing forward;
- neither frail nor gym-styled;
- not an inspirational heroic body;
- posture may be slightly weighted, but not defeated;
- gait should be real, slow, and stable.
## Appearance Anchors
These features should remain stable across views and later shots.
### Head / Face
- dark, slightly messy hair;
- visible stubble;
- middle-aged weathering;
- warm tiredness;
- no polished grooming;
- no fashion portrait expression;
- no dramatic heroic stare.
### Clothing
- dark gray / dark khaki / coal-black long traveler's coat;
- dark restrained inner layer;
- coat has light use traces but is not torn or theatrical;
- coat length and silhouette must remain stable enough for later back-view recognition;
- clothing is practical and road-worn, not branded outdoor fashion.
### Props
- old practical backpack;
- used but not broken;
- medium volume, not oversized, not tactical-fashion, not luxury gear;
- stable enough to identify the traveler from behind.
### Boots
- old walking boots;
- can carry mud;
- durable and road-appropriate;
- not new fashion boots;
- not shoe-ad closeup styling.
## Required Main Board Scope
The main anchor board should be one 16:9 horizontal page on a clean shallow gray-white or very light warm-gray background.
The main board should prioritize identity consistency and execution usefulness over decorative beauty.
### Required Visual Cells
| ID | Cell | Purpose | Priority |
| --- | --- | --- | --- |
| A1 | Front full body | Establish age, body proportion, coat front, inner layer, and overall temperament. | Required |
| A2 | Side full body | Establish side silhouette, jaw/stubble profile, coat fall, and backpack volume. | Required |
| A3 | Back full body | Establish back-view recognition, backpack placement, rear hair outline, and coat hem. | Required |
| B1 | Half-body state | Confirm face age, hair, stubble, eye mood, tired dignity. | Required |
| B2 | Walking side | Confirm gait, coat movement, body weight, and forward motion. | Strongly recommended |
| B3 | Walking back | Confirm the most important later MV silhouette. | Strongly recommended |
| C1 | Coat / inner layer detail | Lock clothing system and color range. | Recommended |
| C2 | Backpack detail | Lock the back-view identity prop. | Recommended |
| C3 | Boots detail | Lock the road / mud / walking identity prop. | Recommended |
### MVP Board If Generation Capacity Is Limited
Minimum acceptable first board:
1. front full body;
2. side full body;
3. back full body;
4. half-body state;
5. short boundary notes or empty annotation zones.
If the model struggles with a full 9-cell board, the next repair strategy should be split generation rather than forcing all requirements into one overloaded image.
## Layout Guidance
Preferred structure:
- top: title / board identity area;
- left: three-view core;
- middle: state views;
- right: clothing and prop breakdown;
- bottom: compact rule / boundary area.
The board should look like a practical film pre-production reference sheet, not a colorful character poster.
### Background
Use:
- shallow gray-white;
- very light neutral gray;
- very light warm gray.
Avoid:
- landscape background;
- city background;
- muddy road background;
- campfire background;
- strong gradient;
- dramatic studio shadow;
- promotional poster background.
Reason:
The background must not interfere with silhouette, coat color, hair shape, backpack form, or boot details.
## Text And Label Strategy
Labels matter, but generated readable text is not reliable enough to carry the source of truth.
For this trial, use this split:
### Image Model Responsibility
The image may include:
- simple visual zones;
- small label-like blocks;
- thin annotation lines;
- empty callout zones;
- minimal non-critical labels if the model can render them cleanly.
The image must not be trusted as the only source for exact Chinese text.
### Document Responsibility
This brief and later prompt/review files carry the authoritative labels:
- age;
- temperament;
- clothing anchors;
- prop anchors;
- allowed drift;
- forbidden drift;
- review checklist.
### Later Layout Responsibility
If a final readable board with exact Chinese labels is needed, add or repair labels in a later page/layout step rather than relying only on image generation.
## Allowed Drift
These variations are acceptable if identity remains stable:
- mild mud or dust;
- wind-worn texture;
- slightly messy hair;
- tired eyes;
- used clothing traces;
- restrained ruggedness;
- small pose variation between views.
## Forbidden Drift
Avoid:
- homeless stereotype;
- drunk stereotype;
- collapse or spiritual defeat;
- fashion model styling;
- polished travel blogger image;
- luxury outdoor gear;
- heroic poster pose;
- arms-open inspirational posture;
- celebrity portrait look;
- glossy game concept art;
- anime / cartoon styling;
- fantasy armor or costume;
- cyberpunk / neon / sci-fi clothing;
- passport-photo style;
- direct front-facing glamour portrait;
- shoe advertisement framing;
- background scene becoming more important than the character.
## Review Questions
Use these questions after the first generated board.
1. Do front, side, and back views clearly look like the same person?
2. Does the back view work without relying on the face?
3. Does walking side / walking back look natural, not posed?
4. Is the traveler tired but still dignified?
5. Are coat, backpack, and boots stable enough to guide later shots?
6. Does the board avoid homeless, drunk, fashion, hero, and travel-blogger drift?
7. If the figure is mentally scaled down to 1/8 or 1/12 of the frame, does the silhouette still read?
8. Is this board useful for later `s01/s10/s46/s47/s51` prompt work?
## Trial-Specific Validation
This brief should support the next prompt-stage validation:
1. Can the `gpt-image-2` Skill template be adapted from generic character-sheet logic to a documentary road-film character board?
2. Can a source photo be used as identity reference without turning the output into a portrait?
3. Can the board preserve identity while keeping the character subordinate to future landscape-led composition?
4. Can the model handle a 9-cell board, or should future workflow prefer split boards?
5. Should exact labels be kept out of image generation and handled later?
## Gated Next Step
After this brief is approved, create:
```text
visual-system/characters/character-anchor-prompt-v1.md
```
That prompt document must:
- run and record the `gpt-image-2` mode check;
- read and record the relevant Skill template/reference files;
- include this brief as a source;
- include the source photo as an explicit identity reference if readable and approved;
- separate image-model output from text annotation responsibilities;
- wait for user approval before generation.

View File

@ -0,0 +1,313 @@
# Character Anchor Prompt V1
## Status
- Document status: pending review.
- Execution status: prompt only; do not generate images before user approval.
- Task type: reference-guided character anchor board generation.
- Project: `在路上`.
- User adjustment: add height `180cm`; make hair longer, beard longer, and beard denser.
## Skill Mode Check
Command:
```powershell
node C:\Users\wangq\.agents\skills\gpt-image-2\scripts\check-mode.js --json
```
Result:
```json
{
"mode": "B-or-C",
"recommendation": "host-or-advisor",
"garden_mode_enabled": false,
"has_api_key": false,
"base_url": "https://api.openai.com/v1",
"model": "gpt-image-2",
"env_flag_value": "(unset)"
}
```
Execution interpretation:
- Garden local generation is not enabled.
- No `OPENAI_API_KEY` is available for Mode A.
- This document uses the `gpt-image-2` Skill as a structured prompt-engineering workflow.
- If image generation is later approved in this Codex environment, use the host image tool path as Mode B.
- If no host image tool is used, this prompt remains an Advisor prompt for external/manual execution.
## Skill References Read
- `C:\Users\wangq\.agents\skills\gpt-image-2\SKILL.md`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\prompt-writing.md`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\portraits-and-characters\character-sheet.md`
Template adaptation:
- Base template family: `portraits-and-characters/character-sheet.md`.
- Adaptation required: the base template targets animation/game/IP character sheets; this project requires a realistic documentary road-film character reference sheet.
- Text policy adaptation: do not rely on generated readable labels as the source of truth.
## Project Sources Used
- `visual-system/characters/character-anchor-trial-plan.md`
- `visual-system/characters/character-anchor-brief-v1.md`
- `intake/阶段四-人物锚点板策划说明.md`
- `intake/阶段四-人物锚点板页面结构建议稿.md`
- `intake/阶段四-人物锚点板文案标注稿.md`
Not used as authoritative source:
- `visual-system/characters/character-anchor-board-v1.md`, because it is a non-generation-ready direct draft.
## Input Image Role
Declared source photo:
```text
C:\Users\wangq\Pictures\照片\photo.jpg
```
Input role:
- identity reference;
- face direction and lived-person basis;
- not an edit target;
- not a passport-photo style target;
- not a requirement to preserve the original photo background, pose, lighting, or clothing.
Readability status:
- not loaded in this document-only step;
- must be loaded or made accessible before generation;
- if the host image tool cannot read the file from this path, copy or approve access before generation.
Declared satisfactory sample:
```text
visual-system/characters/character-chatgpt.png
```
Sample role:
- visual target reference for board structure and character-asset direction;
- use for the clean shallow-gray reference-sheet layout, multi-view organization, dark long coat, old backpack, old boots, restrained working-board tone, and overall satisfactory direction;
- not the primary identity reference;
- not a requirement to copy every facial detail exactly;
- not a final accepted asset until reviewed in this workflow.
## Prompt Strategy
Use one generated board to test whether a single image can stabilize the traveler identity.
Primary output:
- one 16:9 horizontal character anchor board;
- clean shallow gray-white / very light warm-gray background;
- same traveler shown across multiple views;
- realistic film pre-production reference style;
- minimal label zones, not text-heavy layout.
Do not ask the image model to render exact Chinese labels as the source of truth. Exact labels and review criteria remain in project documents.
If the full 9-cell board fails, the next iteration should split the work instead of forcing all requirements into one overloaded prompt.
## Rendered Prompt
Use the attached source photo as Input Image 1. Treat Input Image 1 only as an identity reference for the traveler's face direction, lived-person basis, age impression, hair/stubble direction, and facial structure. Do not copy the original photo background, pose, lighting, clothing, or passport-photo style.
Use the attached `character-chatgpt.png` sample as Input Image 2 if available. Treat Input Image 2 as a visual target reference for the clean shallow-gray character-sheet layout, multi-view organization, dark long coat, old backpack, old boots, working-board tone, and overall satisfactory direction. Do not treat Input Image 2 as the primary identity source.
Generate one 16:9 horizontal realistic character anchor board for the music-video project "在路上". The board is a practical film pre-production reference sheet for a landscape-led road documentary / poetic realism MV. It is not a finished MV shot, not a poster, not a portrait, and not promotional art.
The character is a 50-year-old male traveler, about 180cm tall, translated from the identity reference into a road-film figure: weathered by life and systems, warm but tired, lonely but steady, silent and not defeated. He should feel capable of continuing forward. He is not frail, not gym-styled, not heroic, not fashionable, not homeless-coded, and not drunk-coded.
Overall visual style: realistic documentary character reference, restrained cinematic realism, practical working board, clean shallow gray-white or very light warm-gray background, soft neutral lighting, readable silhouettes, low saturation, no dramatic scene lighting, no landscape or city background. The board should help later image generation keep the same traveler recognizable in wide road shots, back views, side views, muddy-road shots, city-edge shots, and night-fire shots.
Character fixed attributes:
- dark, slightly messy, somewhat longer hair;
- longer and denser beard/stubble, visibly fuller than light stubble but still realistic and restrained;
- weathered middle-aged face with tired dignity;
- dark gray / dark khaki / coal-black long traveler's coat;
- dark restrained inner layer;
- old practical backpack, medium volume, used but not broken;
- old walking boots, durable and road-worn, able to carry mud;
- body posture slightly weighted but not defeated;
- gait slow, real, and stable.
Board layout:
- top area: a quiet board identity area, with minimal title-like visual treatment but no reliance on readable text;
- left area: three-view core with front full body, side full body, and back full body at consistent scale;
- middle area: state views with half-body state, walking side view, and walking back view;
- right area: clothing and prop detail cells for long coat / inner layer, old backpack, and old boots;
- bottom area: compact visual rule strip or empty annotation zone for later labels.
Cell requirements:
1. Front full body: establish age, body proportion, coat front, inner layer, and overall temperament.
2. Side full body: establish side silhouette, jaw/stubble profile, coat fall, and backpack volume.
3. Back full body: establish rear hair outline, backpack placement, coat hem, and back-view recognition.
4. Half-body state: confirm hair, stubble, tired eyes, and dignified middle-aged presence.
5. Walking side: show real forward motion, coat movement, shoulder weight, and stable gait.
6. Walking back: emphasize the later MV silhouette; back view must still feel like the same traveler.
7. Coat / inner layer detail: show dark, practical, road-worn clothing, not fashion styling.
8. Backpack detail: old practical backpack, used but not broken, not tactical fashion, not oversized.
9. Boots detail: old walking boots, durable, slightly muddy or worn, not new fashion shoes and not shoe-ad framing.
Text and label handling:
- The image may include thin callout lines, simple label blocks, empty annotation zones, or simple alphanumeric badges.
- Do not render long readable Chinese or English labels.
- Do not make the image depend on exact text correctness.
- Leave enough clean space for later document/page labels if needed.
Composition priorities:
- same-person consistency across all views;
- back-view recognition without the face;
- stable coat / backpack / boots system;
- clear silhouette when mentally scaled down;
- restrained working-board design;
- character identity over decorative beauty.
Avoid all of the following:
- front-facing glamour portrait;
- passport photo style;
- heroic poster stance;
- arms-open inspirational pose;
- fashion editorial styling;
- polished travel blogger image;
- luxury outdoor gear;
- homeless stereotype;
- drunk stereotype;
- collapse, pity, or spiritual defeat;
- celebrity portrait look;
- glossy game concept art;
- anime / cartoon styling;
- fantasy armor or costume;
- cyberpunk, neon, sci-fi, UI, code, futuristic clothing;
- muddy road scene background;
- city background;
- campfire background;
- strong gradient background;
- dramatic studio shadow;
- shoe advertisement framing;
- text-heavy page;
- exact readable Chinese text as a critical output requirement;
- multiple different men instead of one consistent traveler.
The result should feel like a usable character standard sheet for the road-film traveler: a person whose face, hair, stubble, coat, backpack, boots, posture, and walking silhouette can guide later landscape-led MV images while keeping the world larger than the person.
## Structured Prompt Map
```json
{
"type": "realistic_documentary_character_anchor_board",
"goal": "Generate a 16:9 character anchor board that stabilizes the same traveler across front, side, back, state, walking, clothing, backpack, and boot references for later MV shot generation.",
"input_images": [
{
"id": "Input Image 1",
"path": "C:\\Users\\wangq\\Pictures\\照片\\photo.jpg",
"role": "identity reference",
"use": "face direction, lived-person basis, age impression, longer hair / denser beard direction, facial structure",
"do_not_use_for": "passport-photo style, exact pose, original background, original lighting, original clothing"
},
{
"id": "Input Image 2",
"path": "projects/2026-06-23-在路上/visual-system/characters/character-chatgpt.png",
"role": "visual target reference",
"use": "clean shallow-gray character-sheet layout, multi-view organization, dark long coat, old backpack, old boots, restrained working-board tone, satisfactory direction",
"do_not_use_for": "primary identity source, exact face copy, final acceptance without review"
}
],
"character": {
"identity": "50-year-old male traveler",
"height": "about 180cm",
"temperament": "weathered by life and systems, warm but tired, lonely but steady, silent and not defeated",
"hair": "dark, slightly messy, somewhat longer",
"face": "longer and denser beard/stubble, visibly fuller than light stubble, weathered middle-aged face, tired dignity",
"clothing": "dark gray / dark khaki / coal-black long traveler's coat, dark restrained inner layer",
"props": "old practical backpack, medium volume, used but not broken",
"boots": "old walking boots, durable, road-worn, can carry mud",
"body_presence": "capable of continuing forward, neither frail nor gym-styled"
},
"layout": {
"aspect_ratio": "16:9 horizontal",
"background": "clean shallow gray-white or very light warm-gray",
"style": "practical film pre-production character reference sheet",
"sections": [
"front full body",
"side full body",
"back full body",
"half-body state",
"walking side",
"walking back",
"coat / inner layer detail",
"backpack detail",
"boots detail"
],
"text_policy": "minimal label-like zones only; no long readable Chinese or English labels; exact labels belong in project documents"
},
"constraints": {
"must_keep": [
"same person across all views",
"back-view recognition without face",
"stable long coat / backpack / boots system",
"tired dignity rather than collapse",
"usable silhouette for later wide shots"
],
"avoid": [
"portrait MV framing",
"fashion model styling",
"homeless or drunk coding",
"hero poster pose",
"travel blogger image",
"passport photo style",
"text-heavy board",
"exact readable text dependency",
"multiple different men"
]
}
}
```
## Acceptance Checklist
Review after generation:
1. Front, side, and back views look like the same person.
2. Back view is recognizable without relying on the face.
3. Walking side and walking back are natural, not posed.
4. The figure is tired but dignified, not collapsed.
5. Coat, backpack, and boots are stable enough for later shot prompts.
6. The board avoids homeless, drunk, fashion, hero, and travel-blogger drift.
7. The silhouette would remain identifiable at 1/8 or 1/12 frame scale.
8. The image does not depend on exact generated text.
9. The board is useful for later `s01/s10/s46/s47/s51` prompt work.
## Repair Strategy
If the first generation fails:
- If views look like different people: reduce scope to front / side / back / half-body MVP and regenerate.
- If labels are garbled: remove all readable text requirements and use empty label zones only.
- If the source photo dominates too much: reduce portrait fidelity and emphasize road-film traveler translation.
- If the figure becomes fashionable or heroic: strengthen clothing/proportion/pose negatives.
- If the figure becomes homeless or broken: strengthen dignity and practical-road-worn constraints.
- If nine cells are crowded: split into main board and later prop/detail boards.
## Gated Next Step
Do not generate from this prompt until the user approves this document.
When approved, the generation step must:
1. make `C:\Users\wangq\Pictures\照片\photo.jpg` available to the host image tool as Input Image 1;
2. pass the rendered prompt above to the active image-generation path;
3. save the generated output into the project, not only in a tool default location;
4. create a review record before any transparent character slices.

View File

@ -0,0 +1,163 @@
# Character Anchor Prompt V2
## Status
- Document status: generation test prompt.
- Execution status: used for one Codex host generation test.
- Revision focus: preserve the preferred character image from v1, but correct the walking posture.
- Project: `在路上`.
## Skill Mode Check
Command:
```powershell
node C:\Users\wangq\.agents\skills\gpt-image-2\scripts\check-mode.js --json
```
Result:
```json
{
"mode": "B-or-C",
"recommendation": "host-or-advisor",
"garden_mode_enabled": false,
"has_api_key": false,
"base_url": "https://api.openai.com/v1",
"model": "gpt-image-2",
"env_flag_value": "(unset)"
}
```
Interpretation:
- Use `gpt-image-2` Skill as prompt-engineering workflow.
- Use Codex host image generation path for this test.
- Do not call Garden scripts.
## Revision Inputs
Primary identity reference:
- `C:\Users\wangq\Pictures\照片\photo.jpg`
Preferred character-image reference:
- `visual-system/characters/character-anchor-v1-codex-test.png`
Walking-posture reference:
- `visual-system/characters/character-chatgpt.png`
User feedback:
- Prefer the character image in `character-anchor-v1-codex-test.png`.
- Do not keep the hunched walking pose from `character-anchor-v1-codex-test.png`.
- Walking posture should be closer to `character-chatgpt.png`: upright chest, straighter upper body, not bent at the waist.
## Rendered Prompt
Use the red-background passport-style headshot visible in this conversation as the primary identity reference. Preserve the face direction, lived-person basis, age impression, facial structure, glasses, and general likeness direction, but do not copy the red background, suit, passport-photo pose, lighting, or clothing.
Use `character-anchor-v1-codex-test.png` as the preferred character-image reference. Preserve its overall traveler identity direction: longer messy dark hair, fuller beard, weathered middle-aged face, dark long road-worn coat, old backpack, old boots, shallow gray-white character-board layout, practical documentary reference-sheet tone. This is the preferred character look.
Use `character-chatgpt.png` as the positive walking-posture reference. In walking side and walking back cells, the traveler should walk with an upright chest, a straighter spine, natural head and neck alignment, relaxed shoulders that do not collapse forward, and a forward-moving body that is steady rather than hunched. The walk should feel like a tired but dignified traveler who still carries himself, not a person bent under defeat.
Generate one 16:9 horizontal realistic character anchor board for the music-video project "在路上". The board is a practical film pre-production reference sheet for a landscape-led road documentary / poetic realism MV. It is not a finished MV shot, not a poster, not a portrait, and not promotional art.
The character is a 50-year-old male traveler, about 180cm tall, translated from the identity reference into a road-film figure: weathered by life and systems, warm but tired, lonely but steady, silent and not defeated. He should feel capable of continuing forward. He is not frail, not gym-styled, not heroic, not fashionable, not homeless-coded, and not drunk-coded.
Character fixed attributes:
- dark, slightly messy, somewhat longer hair;
- longer and denser beard/stubble, visibly fuller than light stubble but still realistic and restrained;
- weathered middle-aged face with tired dignity;
- dark gray / dark khaki / coal-black long traveler's coat;
- dark restrained inner layer;
- old practical backpack, medium volume, used but not broken;
- old walking boots, durable and road-worn, able to carry mud;
- body posture solid and capable of continuing forward;
- walking posture upright and steady, not hunched.
Board layout:
- clean shallow gray-white or very light warm-gray background;
- soft neutral lighting;
- low-saturation realistic documentary character reference;
- top area as a quiet board identity zone with minimal title-like visual treatment but no reliance on readable text;
- left area with three-view core: front full body, side full body, back full body at consistent scale;
- middle area with state views: half-body state, walking side view, walking back view;
- right area with clothing and prop detail cells for long coat / inner layer, old backpack, and old boots;
- bottom area as compact visual rule strip or empty annotation zone for later labels.
Cell requirements:
1. Front full body: preserve the preferred v1 character image direction, with solid adult body proportion and road-worn dignity.
2. Side full body: preserve side silhouette and coat/backpack system without making the torso collapse forward.
3. Back full body: preserve back-view recognition, backpack placement, rear hair outline, and coat hem.
4. Half-body state: preserve the preferred v1 face direction, longer hair, fuller beard, tired eyes, and dignified middle-aged presence.
5. Walking side: must show an upright walking posture: chest open, spine straighter, head naturally lifted, shoulders relaxed but not rounded forward. Do not bend the waist. Do not hunch the back. Do not make the traveler look defeated or physically collapsed.
6. Walking back: must show a steady upright back view while walking, with shoulders not folded forward and the backpack sitting naturally.
7. Detail cells: show dark practical road-worn coat, old practical backpack, and old durable boots.
Text and label handling:
- The image may include thin callout lines, simple label blocks, empty annotation zones, or simple alphanumeric badges.
- Do not render long readable Chinese or English labels.
- Do not make the image depend on exact text correctness.
- Leave enough clean space for later document/page labels if needed.
Composition priorities:
- preserve the v1 preferred character image;
- correct the walking posture to be upright like the ChatGPT sample;
- same-person consistency across all views;
- back-view recognition without face;
- stable coat / backpack / boots system;
- clear silhouette when mentally scaled down;
- restrained working-board design;
- character identity over decorative beauty.
Strictly avoid:
- hunched walking posture;
- bent waist in walking side view;
- rounded shoulders collapsing forward;
- bowed head / defeated neck posture;
- stooped, frail, elderly-collapse walk;
- front-facing glamour portrait;
- passport photo style;
- heroic poster stance;
- arms-open inspirational pose;
- fashion editorial styling;
- polished travel blogger image;
- luxury outdoor gear;
- homeless stereotype;
- drunk stereotype;
- collapse, pity, or spiritual defeat;
- celebrity portrait look;
- glossy game concept art;
- anime/cartoon styling;
- fantasy armor or costume;
- cyberpunk/neon/sci-fi/UI/code/futuristic clothing;
- muddy road scene background;
- city background;
- campfire background;
- strong gradient background;
- dramatic studio shadow;
- shoe advertisement framing;
- text-heavy page;
- exact readable Chinese text as a critical output requirement;
- multiple different men instead of one consistent traveler.
The result should keep the preferred v1 traveler image while replacing the hunched walking pose with an upright, chest-open, dignified walking posture similar to the ChatGPT sample.
## Acceptance Delta From V1
V2 passes only if:
1. The character image remains closer to `character-anchor-v1-codex-test.png` than to a new unrelated person.
2. The walking side view is visibly less hunched than v1.
3. The walking side view has an upright chest and a straighter upper body.
4. The walking back view does not read as defeated or collapsed.
5. Coat, backpack, boots, hair, and beard remain stable.

View File

@ -0,0 +1,105 @@
# Character Anchor Review V1
## Status
- Review status: superseded by v2 review.
- Image acceptance state: not final anchor; v2 was accepted later.
- Generation purpose: test Codex host image generation capability and character-anchor workflow completeness.
- Next gated action: completed by `character-anchor-review-v2.md` and `character-identity-lock.md`.
## Generation Context
Prompt document:
- `visual-system/characters/character-anchor-prompt-v1.md`
Generated image:
- `visual-system/characters/character-anchor-v1-codex-test.png`
Tool default source retained:
- `C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_098d4e68be1207f7016a3a2cde9678819889913b70ad004b89.png`
Image properties:
- Width: 1672
- Height: 941
- Pixel format: RGB
- Aspect: close to 16:9
## Inputs Used
### Identity Reference
```text
C:\Users\wangq\Pictures\照片\photo.jpg
```
Role:
- identity reference;
- not edit target;
- not passport-photo style target.
### Satisfactory Sample Reference
```text
visual-system/characters/character-chatgpt.png
```
Role:
- visual target reference for board structure and satisfactory character-asset direction;
- not the primary identity source.
### User Prompt Adjustments
- Add height: about 180cm.
- Hair and beard should be longer.
- Beard should be denser / fuller.
## Privacy Note
External MiniMax visual analysis was attempted for `character-chatgpt.png` but rejected by the environment because sending a project-local image to an external service would be private workspace data exfiltration. The review below is based on local visual inspection only.
## Review Checklist
| Check | Result | Notes |
| --- | --- | --- |
| Front / side / back same-person consistency | Pass | The front, side, and back views read as the same traveler. |
| Back-view recognition without face | Pass | Long coat, backpack, hair shape, and stance are consistent enough for later back-view use. |
| Walking side / walking back naturalness | Pass | Walking side and rear walking pose are natural and not heroic. |
| Tired but dignified | Pass | Face and posture read as restrained, weathered, and dignified rather than collapsed. |
| 180cm body direction | Pass with note | The body reads adult, solid, and tall enough; exact height cannot be verified from the board alone. |
| Longer hair / denser beard | Pass | Compared with the prior sample, hair and beard are clearly longer and fuller. |
| Coat / backpack / boots stability | Pass | The old long coat, backpack, and boots are strong and reusable visual anchors. |
| Avoid homeless / drunk / fashion / hero drift | Pass | It stays practical and road-worn without becoming a fashion shoot or poverty stereotype. |
| Avoid text dependence | Pass | The board uses minimal blocks and empty label areas; exact labels are not required from the image. |
| Usefulness for later five-shot prompts | Pass | Good enough to test character carryover into `s01/s10/s46/s47/s51`. |
## Observed Strengths
- The generated board successfully follows the multi-view character-sheet structure.
- The shallow gray-white background keeps silhouette and clothing readable.
- The dark long coat, old backpack, and old boots are stronger than the face as wide-shot identity anchors.
- The longer hair and fuller beard move the character closer to the requested road-worn traveler image.
- The side and back views are useful for later landscape-led composition.
## Observed Risks
- The result strongly follows the ChatGPT sample layout, which is good for this test but may make future iterations too dependent on one sample.
- The face is directionally related to the source photo, but not a strict likeness match. This may be acceptable because the brief asks for a translated road-film figure, not a portrait copy.
- The board is strong, but still not proof that later wide environmental shots will preserve identity; that must be tested in the five-shot package.
- Exact 180cm cannot be visually audited without scale marks or a comparison object.
## Recommendation
This is a successful process test and a plausible first character anchor candidate.
Recommended next decision:
1. If the user accepts this board as the first character anchor candidate, create `character-identity-lock.md`.
2. If the user wants a tighter likeness to the source photo, regenerate with stronger identity-reference wording.
3. If the user wants less dependency on the ChatGPT sample, regenerate with the same identity but lighter sample-reference wording.
4. Do not start transparent slices until this board is accepted or a repaired version replaces it.

View File

@ -0,0 +1,71 @@
# Character Anchor Review V2
## Status
- Review status: user selected v2.
- Image acceptance state: accepted as the current main character anchor board.
- Generation purpose: repair walking posture while preserving the preferred v1 character image.
- Next gated action: review `character-identity-lock.md` before any transparent slices or scene prompts.
## Generation Context
Prompt document:
- `visual-system/characters/character-anchor-prompt-v2.md`
Generated image:
- `visual-system/characters/character-anchor-v2-codex-posture-test.png`
Tool default source retained:
- `C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_059d9628223dbafb016a3a2f45e45c8198a75f641eb5f2295f.png`
Image properties:
- Width: 1672
- Height: 941
- Pixel format: RGB
- Aspect: close to 16:9
## User Feedback Addressed
Original feedback:
- Character image in `character-anchor-v1-codex-test.png` is preferred.
- Walking posture in v1 is too hunched.
- Regenerate with walking posture closer to `character-chatgpt.png`: upright chest, not bent at the waist.
V2 prompt response:
- Preserved v1 as preferred character-image reference.
- Used `character-chatgpt.png` as positive walking-posture reference.
- Added strict negative constraints against hunched walking, bent waist, rounded shoulders, bowed head, and collapsed posture.
## Review Checklist
| Check | Result | Notes |
| --- | --- | --- |
| Preserve v1 character image direction | Pass | Face, hair, beard, coat, backpack, and boots remain close to v1. |
| Walking side less hunched than v1 | Pass | The main central walking side cell is visibly more upright. |
| Chest / upper body more open | Pass | Main walking pose has a straighter upper body and less collapsed shoulder line. |
| Walking back not defeated | Pass | Rear walking pose is steady and does not read as collapsed. |
| Same-person consistency | Pass | Multi-view identity remains coherent. |
| Coat / backpack / boots stability | Pass | Object system remains strong and consistent. |
| Text dependence avoided | Pass | The board does not rely on exact generated labels. |
## Remaining Notes
- The small lower-left walking pose still has mild forward lean, but it reads as motion rather than waist-bent defeat.
- The main walking side cell is the strongest posture repair and is closer to the desired "挺胸走" direction.
- Compared with v1, v2 has slightly more structured layout and a somewhat less intimate half-body portrait, but the identity direction remains usable.
## Recommendation
V2 is a better candidate than v1 if walking posture is the priority.
Suggested decision:
1. If the user accepts v2, use `character-anchor-v2-codex-posture-test.png` as the first accepted character anchor candidate and create `character-identity-lock.md`.
2. If the user wants one more repair, keep v2 as the base and further specify: "all walking cells must be upright; no secondary walking pose may lean forward."
3. Do not create transparent slices until a character anchor candidate is accepted.

View File

@ -0,0 +1,313 @@
# Character Anchor Trial Plan
## Status
- Document status: pending review.
- Execution status: planning only; do not generate images from this file.
- Scope: character anchor trial for `在路上`.
- Next gated action after approval: rebuild the character anchor prompt through the `gpt-image-2` Skill workflow.
## Why This Plan Exists
The current character work has two separate goals:
1. deliver the character anchor assets needed by this MV project;
2. validate which parts of the character-anchor workflow should become reusable Video Workbench knowledge later.
These goals must stay separate. Project-specific execution should not be mistaken for public workflow rules, and public workflow candidates should not be promoted before they have been tested through real image generation and review.
## Current Issue
`character-anchor-board-v1.md` is a useful content draft, but it is not generation-ready.
Problems:
1. It was drafted directly from project summaries and intake notes instead of the `gpt-image-2` Skill workflow.
2. It does not record Skill mode, template/reference path, or source files actually used.
3. It does not clearly separate image-model responsibilities from later document/page annotation responsibilities.
4. It does not include the user's source photo as an explicit identity reference input.
5. It compresses character-board, transparent-slice, and later execution-asset work into one document.
Therefore, it should be treated only as a non-generation-ready draft and rebuilt before any image generation.
## Source Reliability Assessment
### Primary Sources
These are the most reliable project sources for character-anchor work:
| Source | Role | Reliability |
| --- | --- | --- |
| `intake/阶段四-人物锚点板策划说明.md` | Defines why a character board is needed, background strategy, output types, and review priorities. | High as accepted GPT planning; still requires Codex execution judgment. |
| `intake/阶段四-人物锚点板页面结构建议稿.md` | Defines page structure, layout modules, labels, and review focus. | High for board structure; must be adapted for image-model limits. |
| `intake/阶段四-人物锚点板文案标注稿.md` | Explains why labels matter and which identity features should be stabilized. | High for review logic; image text must be handled carefully. |
| User source photo, once provided/readable | Identity reference for face direction and lived-person basis. | High for identity direction; not an edit target and not a passport-photo style target. |
### Execution Control Sources
These files are useful but secondary:
| Source | Role | Reliability |
| --- | --- | --- |
| `visual-system/visual-system.md` | Condensed accepted visual system and materialization targets. | Reliable summary, but not a substitute for primary intake. |
| `execution-plan.md` | Current phase, batch order, and gate sequence. | Reliable for sequencing, not for detailed prompt construction. |
| `project.md` | Project state and next action. | Reliable for status only. |
### Skill / Workflow Sources
These govern prompt production:
| Source | Role | Reliability |
| --- | --- | --- |
| `gpt-image-2` Skill `SKILL.md` | Required mode-aware workflow for image prompts and generation. | Required workflow source. |
| `gpt-image-2/references/prompt-writing.md` | Template design method: fields, source mapping, parameter strategy. | Required when building structured prompt documents. |
| `gpt-image-2/references/portraits-and-characters/character-sheet.md` | Closest current template for character board / three-view sheet. | Useful but not perfect; must be adapted from anime/IP defaults to documentary road-film character reference. |
| `investigations/2026-06-23-gpt-image-2-advisor-prompt-quality-v2-broader-use-cases/提示词质量综合调研报告.md` | Evidence that Advisor prompts outperform direct prompts for Video Workbench prompt quality. | Strong process evidence; final image quality still unverified. |
## Assessment Of GPT Character Drafts
The three GPT character files are directionally sound but should not be treated as final execution.
### What Looks Reasonable
- Use a shallow gray-white or light warm-gray clean background for the main board.
- Create a board for identity consistency, not a finished MV shot.
- Prioritize front / side / back full-body views.
- Include half-body state, walking side, and walking back to test motion identity.
- Track old coat, old backpack, and old boots as core recognition anchors.
- Review the balance between tiredness and dignity.
- Avoid fashion model, homeless, drunk, hero-poster, and travel-blogger drift.
### What Needs Adaptation
- GPT assumes text labels can be part of the board; image models may create unreliable or fake text.
- GPT mixes main board and transparent slices; these should be separate gated steps.
- GPT gives a human-readable board plan, not a `gpt-image-2` Advisor prompt.
- GPT does not define the source photo role.
- GPT does not separate project-specific identity from reusable character-anchor workflow.
## Should We Extract The GPT Drafts?
Yes, but into two different layers.
### Layer 1: Project Execution Extraction
Extract what this project needs:
- traveler identity;
- board layout;
- view list;
- clothing / prop anchors;
- allowed and forbidden drift;
- source-photo role;
- review checklist;
- generation gate sequence.
This becomes the basis for the rebuilt project prompt.
### Layer 2: Public Workflow Candidate Extraction
Extract what might become reusable later:
- character anchor purpose definition;
- source hierarchy;
- standard deliverables;
- prompt workflow;
- text-label handling rule;
- review rubric;
- gate sequence.
This layer remains a candidate until validated by this trial.
## Project-Specific Character Work Package
The current project should perform the following work, one gated step at a time.
### Step 1: Trial Plan
Output:
- `visual-system/characters/character-anchor-trial-plan.md`
Purpose:
- decide what is being validated;
- separate project work from reusable workflow candidates;
- identify source reliability and prompt-production rules.
Gate:
- user review.
### Step 2: Character Execution Brief
Output:
- `visual-system/characters/character-anchor-brief-v1.md`
Purpose:
- extract the accepted character definition from primary intake sources;
- record source-photo role;
- define required views and objects;
- define review criteria before prompt writing.
Gate:
- user review.
### Step 3: Skill-Based Prompt Document
Output:
- `visual-system/characters/character-anchor-prompt-v1.md`
Purpose:
- run and record the `gpt-image-2` mode check;
- record template/reference files used;
- map source material into a structured Advisor prompt;
- separate image-model output from later annotation/document responsibilities;
- include negative constraints and acceptance criteria.
Gate:
- user review before generation.
### Step 4: Main Character Anchor Board Generation
Output:
- first generated main board image;
- prompt trace if required by the active Skill mode;
- `visual-system/characters/character-anchor-review-v1.md`
Purpose:
- test whether a single board can lock the character consistently enough.
Gate:
- user review before any transparent slices.
### Step 5: Transparent Character Slices
Output candidates:
- front full body;
- side full body;
- back full body;
- walking side;
- walking back.
Purpose:
- create execution references for later shot prompts or compositing reference.
Gate:
- only after main board is accepted.
### Step 6: Character Identity Lock
Output:
- `visual-system/characters/character-identity-lock.md`
Purpose:
- record the accepted stable identity features after image review;
- provide a compact reference for style anchor and five-shot prompt work.
Gate:
- only after at least one board or slice set is accepted.
## Candidate Reusable Character-Anchor Structure
These items are candidates for future Video Workbench knowledge, but should not be promoted until this project validates them.
### Candidate Standard Deliverables
1. `character-anchor-trial-plan.md`
2. `character-anchor-brief-v1.md`
3. `character-anchor-prompt-v1.md`
4. generated main board image
5. `character-anchor-review-v1.md`
6. transparent slices, when needed
7. `character-identity-lock.md`
### Candidate Source Hierarchy
1. user-provided source/reference images;
2. accepted GPT intake files;
3. project-local visual-system summary;
4. project-local execution plan;
5. prior generated assets and review records.
### Candidate Review Rubric
1. same-person consistency across front / side / back;
2. back-view recognition without face;
3. walking state naturalness;
4. identity stability when scaled down;
5. clothing and prop stability;
6. balance between expressive character and non-portrait role;
7. project-specific drift avoidance;
8. usefulness for later shot prompts.
### Candidate Text Responsibility Rule
For image generation, avoid relying on generated readable labels as the source of truth.
Preferred split:
- image model: visual board, views, silhouettes, clothing, props, empty label zones if useful;
- project document: exact labels, review criteria, identity-lock fields;
- later page/layout layer: any final readable Chinese labels if required.
### Candidate Gate Sequence
1. trial plan;
2. execution brief;
3. Skill-based prompt;
4. main board generation;
5. review and repair;
6. transparent slices;
7. identity lock;
8. use in shot tests.
## Trial Validation Questions
This project should answer these questions before any rule becomes public knowledge.
1. Can the three GPT character files be reliably transformed into a concise project execution brief?
2. Does the `gpt-image-2` Advisor workflow produce a better prompt than direct drafting for this character board?
3. Can one generated board maintain same-person consistency across front / side / back / walking views?
4. Does the user's source photo help establish identity without turning the output into a portrait or passport-photo derivative?
5. Are image-model text labels usable, or should all exact labels be handled outside the generated image?
6. Does the accepted main board actually improve later five-shot test prompts?
7. Which review criteria are general enough for future projects, and which are only specific to `在路上`?
## Do Not Promote Yet
The following should not be added to stable knowledge yet:
- a final character-anchor directory standard;
- a mandatory fixed board layout;
- a universal prompt template;
- a universal source-photo policy;
- a claim that text labels should or should not be generated inside the image;
- a claim that one board is enough before transparent slices.
These can be considered only after this trial has produced and reviewed real images.
## Immediate Next Step
After this plan is approved, create:
```text
visual-system/characters/character-anchor-brief-v1.md
```
That brief should use the three GPT character intake files as primary sources, include the source-photo role, and prepare the material for a `gpt-image-2` Skill-based prompt document.

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 575 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 606 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 484 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Some files were not shown because too many files have changed in this diff Show More