Compare commits

...

19 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
685 changed files with 75986 additions and 30 deletions

34
.gitignore vendored
View File

@ -3,3 +3,37 @@ tmp/*
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

168
AGENTS.md
View File

@ -13,6 +13,26 @@ 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:
@ -30,3 +50,151 @@ C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-s
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

@ -15,6 +15,7 @@ It turns accepted planning material and deep source references into public-facin
- video outlines;
- storyboard logic;
- shot-level production files;
- project-specific Remotion source and render receipts;
- voiceover scripts;
- image prompts;
- asset manifests;
@ -31,7 +32,7 @@ It does not own upstream deep creation, canonical agents, reusable automation so
| `writing-workbench` | Sibling workspace for deep article production | completed or sufficiently stable article projects when the user chooses to make video content | no default output |
| `ccpe-system` | Supplier of local work agents, runtime rules, model cards, and governed cognitive assets | the external `Interface.md`, the consumer setup contract, and task-specific canonical artifacts only when routed by the setup/registry | capability requests under `requirements/ccpe/` |
| `skills-vault` | Supplier of deterministic automation tools | file processors, batch utilities, asset tools, export tools, installable automation skills | capability requests under `requirements/skills-vault/` |
| `work-projects` | Separate software/customer project workspace | no default input | production system requirements if this video workflow is later packaged as deployable software |
| `work-projects` | Separate software/customer project workspace | no default input | production system requirements if this video workflow is later packaged as deployable software or a reusable Remotion product/template |
## Boundary Rules
@ -40,6 +41,7 @@ It does not own upstream deep creation, canonical agents, reusable automation so
- Long-term sources, finished essays, model documents, and open-ended discussion memory belong in `knowledge-vault`.
- Canonical local-work agents, prompts, runtimes, model cards, and invocation protocols belong in `ccpe-system`; Video Workbench starts from `ccpe-system\Interface.md`, not from hardcoded internal CCPE artifact paths.
- Deterministic reusable automation implementation source belongs in `skills-vault`.
- One-off project-specific Remotion source belongs under `projects/<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.

View File

@ -1,15 +1,15 @@
# Video Workbench
Video Workbench is the local execution workspace for dimensional video and slide-style output. It receives GPT V2 planning Markdown from the user, keeps lightweight project records, and produces local execution plans, visual-system assets, prompts, images, narration audio, slide/page files, and handoff notes.
Video Workbench is the local execution workspace for dimensional video, Remotion, and slide-style output. It receives GPT planning Markdown from the user, keeps lightweight project records, and produces local execution plans, visual-system assets, prompts, images, Remotion source projects, narration audio, renderable video files, slide/page files, and handoff notes.
It is a sibling of Writing Workbench, not a subfolder of it.
## Working Model
```text
GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons
GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons, Remotion planning briefs
User = decisions, source material, accepted planning files
Video Workbench = stage 6+ execution planning, Prompt Advisor work, visual-system materialization, generated assets, handoff
Video Workbench = stage 6+ execution planning, Prompt Advisor work, Remotion implementation, visual-system materialization, generated assets, handoff
CCPE System = local work agents, runtimes, model cards, interfaces
Skills Vault = reusable automation skills and deterministic tools
```
@ -28,6 +28,10 @@ projects/
visual-system.md
refs/
iterations/
remotion/
package.json
src/
public/
slides/
slides.md
s01/
@ -43,10 +47,11 @@ ccpe-consumption/
```
- `projects/` is the only project entry point. Project status and series membership are recorded inside project files, not by moving directories.
- `projects/<project>/intake/` holds user-provided GPT V2 stage 0-5 Markdown, source notes, references, and other accepted inputs.
- `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.
@ -58,8 +63,10 @@ Series indexes can be added later under `projects/_series/` when a real series n
## Boundaries
- Manual editing and publishing remain human-controlled unless explicitly automated later.
- Video Workbench does not default to full video editing, image-to-video generation, or platform publishing.
- Codex does not ask GPT V2 for final image prompts, Codex JSON, output paths, task lists, or image generation parameters.
- Video Workbench does not default to full manual video editing, image-to-video generation, or platform publishing.
- Codex does not ask GPT for final image prompts, Codex JSON, output paths, task lists, dependency commands, render commands, or complete Remotion source code.
- For Remotion videos, accepted GPT planning can supply adaptation judgment, a style-system anchor, storyboard-to-component mapping, and a Remotion Implementation Brief. Codex owns the local source layout, implementation, dependency commands, render commands, and validation.
- The default Remotion deliverable is source code plus a renderable MP4. The user has standing task-level permission for `npx create-video`, npm dependency installation, and Remotion render commands when a Remotion task needs them; sandbox or network approvals may still be requested at command time.
- `makeup-still/` is not a recommended project directory. Character, scene, template, diagram, and background anchors belong under `visual-system/` when needed.
- `tmp/` is deprecated. New reusable or reviewable investigation material belongs under `investigations/`.
- Missing CCPE assets should be requested under `requirements/ccpe/`.

View File

@ -2,19 +2,21 @@
## 1. Workspace Identity
This project is the local execution workspace for dimensional video and slide-style output.
This project is the local execution workspace for dimensional video, Remotion, and slide-style output.
It turns accepted GPT V2 planning Markdown and user-provided sources into project notes, local execution plans, visual-system assets, slide/page execution folders, generated assets, and handoff material. It is optimized for practical continuation, not heavy governance.
It turns accepted GPT planning Markdown and user-provided sources into project notes, local execution plans, visual-system assets, slide/page execution folders, Remotion source projects, generated assets, renderable video files, and compact handoff material. It is optimized for practical continuation and production throughput, not heavy governance.
## 2. Collaboration Roles
```text
GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons
GPT / ChatGPT = stage 0-5 planning Markdown, outlines, visual systems, page/shot skeletons, Remotion planning briefs
User = decisions, accepted inputs, source/reference material
Codex = stage 6+ execution planning, Prompt Advisor work, visual-system materialization, iteration, local assets
Codex = stage 6+ execution planning, Prompt Advisor work, Remotion implementation, visual-system materialization, iteration, local assets
```
GPT V2 does not provide final image prompts, Codex JSON, output paths, task lists, or image generation parameters. Codex should not request those from GPT as missing inputs.
GPT does not provide final image prompts, Codex JSON, output paths, task lists, dependency commands, render commands, complete Remotion source code, or image generation parameters. Codex should not request those from GPT as missing inputs.
For Remotion videos, accepted planning from `强哥的策划导演3.0` may provide Remotion adaptation judgment, a Remotion style-system anchor, storyboard-to-component mapping, and a Remotion Implementation Brief. The brief is a planning source, not a Codex execution package.
Codex should not rewrite GPT planning into duplicate project content. The accepted planning files belong in the project `intake/` directory, and Codex turns them into local execution decisions in `execution-plan.md`.
@ -32,10 +34,15 @@ projects/
visual-system.md
refs/
iterations/
remotion/
package.json
src/
public/
slides/
slides.md
s01/
s02/
tasks/
```
Use root-level `handoff/` for repository-level, cross-project, series-level, or context-window handoff notes.
@ -51,9 +58,13 @@ If a series needs more structure, create `projects/_series/` when the first real
`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 V2 planning Markdown, source notes, reference notes, or background notes;
- which `intake/` files are GPT planning Markdown, source notes, reference notes, or background notes;
- Remotion source root when applicable, defaulting to `projects/<project>/remotion/`;
- current execution focus;
- key local execution files;
- next action.
@ -68,11 +79,20 @@ Visual projects must have:
projects/<project>/execution-plan.md
```
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;
@ -84,14 +104,56 @@ It should not repeat the project ID, full intake file index, or project map from
`projects/<project>/intake/` holds material provided or accepted by the user:
- GPT V2 stage 0-5 planning Markdown;
- GPT stage 0-5 planning Markdown;
- outlines;
- storyboards, page skeletons, or shot skeletons;
- Remotion adaptation judgments, Remotion style-system anchors, Remotion storyboards, storyboard-to-component mappings, and Remotion Implementation Briefs;
- background notes;
- reference images, audio notes, or source pointers.
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:
@ -120,17 +182,29 @@ 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 both video shots and PPT-style pages.
Use `slides/` as the execution unit area for video shots, PPT-style pages, Remotion scenes, and Remotion sections.
`projects/<project>/slides/slides.md` is the unit execution fact table. It records each page or shot's source, batch, current prompt version, current image version, review state, acceptance state, and notes. Project-level iteration strategy belongs in `execution-plan.md`.
`projects/<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, or shot together:
Each `slides/sNN/` folder keeps one slide, page, shot, Remotion scene, or Remotion section together:
```text
slides/
@ -138,17 +212,123 @@ slides/
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-review.md
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
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.
@ -172,11 +352,63 @@ Adjust only when the user specifies a different narration speed.
Image and audio generation can be automated when available skills or APIs are appropriate.
Video generation from images remains manual or semi-manual for now because output reliability varies.
Video generation from images remains manual or semi-manual for now because output reliability varies. Remotion is a separate programmatic video path: use it when the accepted plan calls for React/TypeScript animation, scene composition, captions, charts, diagrams, or renderable MP4 output from source code.
Editing and publishing are human-controlled unless explicitly automated later.
Codex is the default prompt owner for final image prompts in this workspace. It may use `gpt-image-2` Advisor or other image tools, but GPT V2 planning Markdown remains a source specification, not a final prompt.
Codex is the default prompt owner for final image prompts in this workspace, but final prompts must be produced through the `gpt-image-2` Skill workflow rather than direct freehand drafting. GPT planning Markdown remains a source specification, not a final prompt.
For project-bound image prompts, Codex must:
- 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.
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.
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.
### 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
@ -222,4 +454,4 @@ C:\Users\wangq\Documents\Codex\ccpe-system\runtimes\hybrid\ccpe-agent-consumer-s
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.
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.
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,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

@ -14,19 +14,21 @@ Skills Vault = reusable automation skill supplier
Video Workbench is a sibling of Writing Workbench. It should not be folded into article production because the target output, rhythm, assets, and evaluation criteria are different.
Video Workbench keeps local project notes, execution outputs, and handoff records. It does not own canonical prompts, agent definitions, reusable automation source code, or production/business agent implementation for deployable systems.
Video Workbench keeps local project notes, execution outputs, Remotion source for one-off project videos, and handoff records. It does not own canonical prompts, agent definitions, reusable automation source code, reusable Remotion products/templates, or production/business agent implementation for deployable systems.
## Collaboration Contract
```text
GPT / ChatGPT = stage 0-5 planning Markdown, visual-system design, page/shot skeletons
GPT / ChatGPT = stage 0-5 planning Markdown, visual-system design, page/shot skeletons, Remotion planning briefs
User = decisions and accepted input placement
Codex = stage 6+ execution planning, Prompt Advisor work, visual-system materialization, iteration, generated assets
Codex = stage 6+ execution planning, Prompt Advisor work, Remotion implementation, visual-system materialization, iteration, generated assets
```
Most planning files should come from GPT V2 output accepted by the user and placed in `projects/<project>/intake/`. Codex-maintained files should be local execution aids and execution records.
Most planning files should come from GPT output accepted by the user and placed in `projects/<project>/intake/`. Codex-maintained files should be local execution aids and execution records.
Codex should not ask GPT V2 for final image prompts, Codex JSON, output paths, task lists, or image generation parameters. GPT V2 planning Markdown is a source specification, not an execution command.
Codex should not ask GPT for final image prompts, Codex JSON, output paths, task lists, dependency commands, render commands, complete Remotion source code, or image generation parameters. GPT planning Markdown is a source specification, not an execution command.
For Remotion videos, accepted planning from `强哥的策划导演3.0` can provide Remotion adaptation judgment, a Remotion style-system anchor, storyboard-to-component mapping, and a Remotion Implementation Brief. Codex turns that into local source code, tool commands, render checks, MP4 outputs, and compact project records.
## Project Shape
@ -51,6 +53,10 @@ projects/<project-id>/
visual-system.md
refs/
iterations/
remotion/
package.json
src/
public/
slides/
slides.md
s01/
@ -65,15 +71,17 @@ Use `docs/cases/` as the local Codex case-pattern library. It is allowed to extr
`project.md` is a Codex-maintained small note. It should link to intake files and key local execution files instead of duplicating the outline, storyboard, page design, or execution plan.
`intake/` holds GPT V2 stage 0-5 planning Markdown, user-provided source material, references, and other accepted input files.
`intake/` holds GPT stage 0-5 planning Markdown, user-provided source material, references, and other accepted input files.
`execution-plan.md` is the visual project's local execution control file. It records the current medium branch, visual-system materialization targets, small-batch iteration strategy, active `sNN` units, current round, and next decision. It does not repeat the project map from `project.md`.
`visual-system/visual-system.md` records the current accepted visual system, materialization targets, iteration log, failure attribution, and next action. Character anchors, scene anchors, templates, diagrams, and backgrounds belong under `visual-system/`, not a separate `makeup-still/`.
`remotion/` is the default source root for one-off project-specific Remotion videos. It should hold source code, package files, and source assets. Generated renders, caches, dependencies, and build outputs stay out of Git by default. Reusable Remotion products/templates belong in `work-projects` unless the user explicitly keeps a prototype local.
`slides/slides.md` is the slide/page/shot execution fact table. It records each unit's source, batch, prompt version, image version, review state, acceptance state, and notes. It does not replace `execution-plan.md`.
`slides/sNN/` keeps all files for one slide, page, or shot together: prompts, narration, generated images, generated audio, review notes, and local notes. Every file inside `sNN/` must carry the `sNN` prefix; iteration files use `sNN-vN-type.ext`, such as `s03-v1-prompt.md`.
`slides/sNN/` keeps all files for one slide, page, shot, Remotion scene, or Remotion section together: prompts, narration, generated images, generated audio, component/spec notes, review notes, and local notes. Every file inside `sNN/` must carry the `sNN` prefix; iteration files use `sNN-vN-type.ext`, such as `s03-v1-prompt.md`.
## Investigations
@ -105,7 +113,9 @@ Produce a video usually under 10 minutes.
Use about 220 Chinese characters per minute as the narration budget.
```
Editing and publishing remain manual unless explicitly automated later. Image-to-video remains manual or semi-manual for now.
Editing and publishing remain manual unless explicitly automated later. Image-to-video remains manual or semi-manual for now. Remotion videos are the exception for programmatic assembly: default project-specific source goes under `projects/<project>/remotion/`, and the default deliverable is source code plus a renderable MP4.
The user has given standing task-level permission for Remotion tasks to use `npx create-video`, npm dependency installation, and Remotion render commands when needed. The agent must still use normal sandbox/network approval requests when a command requires escalation.
## Capability-Request Mode

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

@ -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.

View File

@ -10,6 +10,8 @@ Investigation files are not stable operating rules by themselves. Accepted concl
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:
@ -17,4 +19,6 @@ 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

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 380 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 860 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 394 KiB

View File

@ -0,0 +1,105 @@
# Character Transparent Slice Front Repair V2
## Status
- Review status: accepted as part of the v2-from-anchor transparent slice set.
- Scope: front full-body slice only.
- Repair reason: the first generated transparent slice set drifted away from the accepted v2 character anchor.
- Repair strategy: derive the front slice directly from the accepted v2 anchor board instead of regenerating a new person from text.
- Next gated action: completed by `character-transparent-slices-v2-from-anchor-review.md`.
## Source
Accepted anchor board:
```text
visual-system/characters/character-anchor-v2-codex-posture-test.png
```
Source crop:
```text
visual-system/characters/character-anchor-v2-front-reference-crop-tight.png
```
Final alpha PNG candidate:
```text
visual-system/characters/character-slice-front-v2-from-anchor.png
```
Preview:
```text
visual-system/characters/character-slice-front-v2-from-anchor-preview.png
```
## Execution Method
This repair did not use independent prompt-only generation.
Method:
1. Crop the front full-body standing figure from the accepted v2 anchor board.
2. Remove the light board background locally.
3. Save the result as a transparent PNG.
4. Preserve the old rejected v1 front slice as failed-trial evidence.
Crop box from the v2 board:
```text
(20, 104, 264, 835)
```
Local processing environment:
```text
C:\Users\wangq\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe
```
## Validation
Final file:
```text
visual-system/characters/character-slice-front-v2-from-anchor.png
```
Validation result:
| Check | Result |
| --- | --- |
| Mode | RGBA |
| Size | 488x1440 |
| Four corners transparent | Pass: `[0, 0, 0, 0]` |
| Source identity | Directly derived from accepted v2 front figure |
| New-person generation risk | Avoided |
Alpha summary:
```text
transparent=247699
partial=33986
opaque=421035
```
## Review Notes
Strengths:
- Identity matches v2 because the figure is cropped from v2 itself.
- Front face, glasses, hair, beard, coat, backpack straps, pants, and boots are preserved.
- No new prompt-only person was synthesized.
- Full body is retained.
Known limitations:
- Resolution is limited by the front cell inside the 16:9 anchor board.
- Some soft edge cleanup is image-processing based, not model-native transparency.
- This is a better identity anchor than the rejected v1 front slice, but not a high-resolution regenerated character render.
## Recommendation
Use this as the front transparent-slice candidate if identity fidelity is more important than maximum resolution.
After user approval, repair `side` using the same principle: derive or reference-bind from the accepted v2 anchor board first, rather than text-only regeneration.

Binary file not shown.

After

Width:  |  Height:  |  Size: 389 KiB

View File

@ -0,0 +1,325 @@
# Character Transparent Slices Prompt V1
## Status
- Document status: used for first generation batch.
- Execution status: five slice candidates generated; review pending.
- Project: `在路上`.
- Asset step: character transparent slices after accepted v2 main character anchor board.
- Review file: `visual-system/characters/character-transparent-slices-review-v1.md`.
## Purpose
Create five transparent character cutout references for later MV shot prompting and possible compositing reference.
The slices are not final MV frames. They are execution assets that should preserve the accepted character identity while removing scene background influence.
Required slice set:
| ID | Output candidate | Purpose |
| --- | --- | --- |
| `front` | front full body | Locks body proportion, coat front, face / hair / beard direction. |
| `side` | side full body | Locks side silhouette, coat fall, backpack volume, profile. |
| `back` | back full body | Locks back-view recognition without face. |
| `walk-side` | walking side full body | Tests the upright walking posture required for road shots. |
| `walk-back` | walking back full body | Tests the most important later wide-shot silhouette. |
## Skill Workflow Record
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)"
}
```
Interpretation:
- Use `gpt-image-2` as the prompt-engineering workflow.
- Garden local generation is not enabled.
- This Codex environment has a host image-generation path, so later execution should be treated as Mode B if the user approves generation.
- No Garden scripts should be called for this step.
Skill files actually 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`
- `C:\Users\wangq\.agents\skills\gpt-image-2\references\portraits-and-characters\pose-reference-sheet.md`
Template adaptation:
- `character-sheet.md` provides the front / side / back view logic.
- `pose-reference-sheet.md` provides the same-character / pose-variation control logic.
- This project adapts both into five independent transparent cutout prompts, not a full character board.
## Source Files Actually Used
Primary project sources:
- `visual-system/characters/character-identity-lock.md`
- `visual-system/characters/character-anchor-review-v2.md`
- `visual-system/characters/character-anchor-prompt-v2.md`
Visual references:
- `visual-system/characters/character-anchor-v2-codex-posture-test.png`: accepted main character anchor board.
- `visual-system/characters/character-anchor-v1-codex-test.png`: preferred original character-image direction.
- `visual-system/characters/character-chatgpt.png`: positive upright walking posture / board-quality reference.
Identity reference:
```text
C:\Users\wangq\Pictures\照片\photo.jpg
```
Role:
- identity reference only;
- not an edit target;
- not a passport-photo style target;
- use only to preserve the lived-person basis and face direction when the execution tool supports image references.
## Asset Format
Preferred output:
- five separate PNG images;
- transparent alpha background;
- one full-body character per image;
- no scene, no floor, no horizon, no labels, no board layout;
- full body must be fully inside the canvas, including head, coat hem, backpack, hands, boots, and any stride extension;
- consistent character scale across all five images.
Preferred canvas:
- individual vertical cutout canvas, about 2:3 or 3:4;
- if the host tool only supports a horizontal frame, center the character and keep enough empty transparent margin for cropping.
Transparency fallback:
- If true alpha transparency is unavailable, use a completely flat, clean, uniform near-white or very light neutral matte background with no texture and no shadow; mark the result as non-transparent fallback in the review.
## Character Lock For All Slices
Every slice must depict the same person:
- 50-year-old male traveler;
- about 180cm tall;
- black rectangular glasses;
- dark, somewhat longer, slightly messy hair;
- visible gray / white streaks allowed;
- longer, denser beard / stubble, fuller than light stubble but still realistic and controlled;
- weathered middle-aged face;
- quiet, serious, tired expression with dignity;
- solid adult body, capable of continuing forward;
- dark gray / dark khaki / coal-black long traveler's coat;
- dark restrained inner layer;
- old dark pants;
- old practical medium-volume backpack, worn / dusty but not broken;
- old durable walking boots, road-worn and able to carry mud.
Character temperament:
- weathered by life and systems;
- warm but tired;
- lonely but steady;
- silent and not defeated;
- tired but dignified;
- road-worn, not ragged.
## Critical Posture Rule
For all standing and walking slices:
> The traveler may look tired, but he must not walk or stand with a bent waist, hunched back, rounded collapsed shoulders, bowed defeated head, or physically broken body.
Walking slices must show:
- upright chest;
- straighter spine;
- natural head and neck alignment;
- relaxed shoulders that do not collapse forward;
- steady forward movement;
- grounded but dignified gait.
## Shared Negative Constraints
Strictly avoid:
- hunched walking posture;
- bent waist;
- rounded shoulders collapsing forward;
- bowed defeated head;
- collapsed, frail, or physically broken body;
- homeless stereotype;
- drunk stereotype;
- pity image or spiritual defeat;
- fashion model styling;
- polished travel blogger image;
- luxury outdoor gear;
- heroic poster stance;
- arms-open inspirational pose;
- celebrity portrait look;
- glossy game concept art;
- anime / cartoon styling;
- fantasy armor or costume;
- cyberpunk / neon / sci-fi / futuristic clothing;
- passport-photo style;
- front-facing glamour portrait;
- scenery background;
- city background;
- muddy road background;
- campfire background;
- dramatic studio shadow;
- text labels, captions, logos, UI, frames, borders, or annotation lines;
- multiple different men instead of the same traveler.
## Base Prompt Block
Use this base block for all five slice prompts:
```text
Create one realistic full-body transparent PNG character cutout for the music-video project "在路上".
Use the accepted character anchor board `character-anchor-v2-codex-posture-test.png` as the primary visual identity reference. Preserve the same 50-year-old male road traveler: about 180cm tall, black rectangular glasses, longer messy dark hair with possible gray/white streaks, longer and denser realistic beard/stubble, weathered middle-aged face, quiet tired dignity, solid adult body, dark gray / dark khaki / coal-black long road-worn traveler's coat, dark restrained inner layer, old dark pants, old practical medium-volume backpack, and old durable walking boots.
Use the source photo only as an identity reference if image-reference input is supported. Do not copy its red background, passport-photo pose, suit, lighting, or portrait framing.
The image is an isolated execution asset, not a final MV frame and not a character board. One full-body character only. Transparent alpha background. No scenery, no floor texture, no horizon, no text, no labels, no frame, no UI, no props other than the backpack and clothing system. Keep the whole body fully inside the canvas with clean transparent margins.
Style: realistic cinematic pre-production character cutout, low-saturation documentary road-film feeling, practical and restrained, not anime, not cartoon, not glossy game concept art, not fashion editorial.
The traveler may look tired, but he must not look collapsed, frail, homeless-coded, drunk-coded, heroic, or defeated.
```
## Slice Prompt 1: Front Full Body
Output candidate:
```text
visual-system/characters/character-slice-front-v1.png
```
Prompt:
```text
[BASE PROMPT BLOCK]
Pose requirement: front full-body standing view. The traveler faces the camera naturally, feet grounded, shoulders relaxed, coat front visible, backpack straps or side edges visible if natural, hands neutral and unobtrusive. The body should feel tall, solid, and capable of walking, not heroic and not posed for a fashion portrait.
Purpose: lock age impression, body proportion, coat front, glasses, longer hair, fuller beard, and tired but dignified face direction.
```
## Slice Prompt 2: Side Full Body
Output candidate:
```text
visual-system/characters/character-slice-side-v1.png
```
Prompt:
```text
[BASE PROMPT BLOCK]
Pose requirement: clean side full-body standing view, profile direction, full head-to-boots silhouette visible. Show the coat fall, backpack thickness and placement, profile of glasses, hair outline, beard profile, and boot shape. The torso must not collapse forward. Keep the spine naturally upright and the head aligned.
Purpose: lock side silhouette and backpack volume for later landscape-led side-view shots.
```
## Slice Prompt 3: Back Full Body
Output candidate:
```text
visual-system/characters/character-slice-back-v1.png
```
Prompt:
```text
[BASE PROMPT BLOCK]
Pose requirement: back full-body standing view. The traveler faces away from the camera. Show stable back-view recognition: longer messy hair outline, old medium backpack centered on the back, long dark coat from shoulders to lower body, old pants, and road-worn boots. Shoulders are relaxed but not folded forward.
Purpose: lock the no-face identity used in distant MV shots.
```
## Slice Prompt 4: Walking Side Full Body
Output candidate:
```text
visual-system/characters/character-slice-walk-side-v1.png
```
Prompt:
```text
[BASE PROMPT BLOCK]
Pose requirement: side full-body walking view, one step forward, natural road-walking gait. The traveler walks with upright chest, straighter spine, natural head and neck alignment, and relaxed shoulders that do not collapse forward. The coat moves slightly with the step, backpack sits naturally, boots show grounded forward motion.
Critical rule: do not bend the waist, do not hunch the back, do not bow the head, do not make him look physically broken or defeated. The walk should feel tired but dignified, steady, and capable of continuing.
Purpose: lock the main side-walking silhouette for road shots.
```
## Slice Prompt 5: Walking Back Full Body
Output candidate:
```text
visual-system/characters/character-slice-walk-back-v1.png
```
Prompt:
```text
[BASE PROMPT BLOCK]
Pose requirement: back full-body walking view, the traveler moving away from the camera. Show a steady upright back, natural backpack placement, long coat movement, grounded boot stride, and the same longer hair outline. The body should read as continuing forward, not slumping away.
Critical rule: shoulders must not fold forward, spine must not hunch, head must not droop in defeat. The back view should feel lonely and tired but still dignified.
Purpose: lock the most important no-face walking silhouette for later wide shots.
```
## Review Checklist
After generation, create a review file and check:
1. Do all five slices depict the same traveler?
2. Does the face / hair / beard / glasses system stay close to the accepted v2 anchor?
3. Do coat, backpack, pants, and boots remain stable across all slices?
4. Are the walking side and walking back slices upright enough?
5. Are head, coat hem, hands, backpack, and boots fully inside the canvas?
6. Is the background truly transparent, or only a fallback matte?
7. Does the side view preserve backpack volume without torso collapse?
8. Does the back view work without face details?
9. Do the assets avoid fashion, hero, homeless, drunk, and defeated-body drift?
10. Are the cutouts useful for later `s01`, `s10`, `s46`, `s47`, and `s51` prompt work?
## Next Gated Action
Only after user approval:
1. generate the five slice candidates;
2. save them under `visual-system/characters/`;
3. create `character-transparent-slices-review-v1.md`;
4. do not proceed to the common style anchor board until the slice review is accepted or intentionally skipped.

View File

@ -0,0 +1,152 @@
# Character Transparent Slices Review V1
## Status
- Review status: not accepted by user.
- Generation status: completed first five-slice batch.
- Prompt/spec source: `visual-system/characters/character-transparent-slices-prompt-v1.md`.
- Main identity source: accepted v2 character anchor board and `character-identity-lock.md`.
- User rejection reason: the generated slices no longer look like the accepted v2 character anchor.
- Next gated action: repair one slice at a time, starting from identity-critical front full body, before any style-anchor or five-shot work uses transparent character assets.
## Generated Assets
Final alpha PNG slices:
| Slice | Final file | Source chroma file |
| --- | --- | --- |
| Front full body | `visual-system/characters/character-slice-front-v1.png` | `visual-system/characters/character-slice-front-v1-chroma-src.png` |
| Side full body | `visual-system/characters/character-slice-side-v1.png` | `visual-system/characters/character-slice-side-v1-chroma-src.png` |
| Back full body | `visual-system/characters/character-slice-back-v1.png` | `visual-system/characters/character-slice-back-v1-chroma-src.png` |
| Walking side | `visual-system/characters/character-slice-walk-side-v1.png` | `visual-system/characters/character-slice-walk-side-v1-chroma-src.png` |
| Walking back | `visual-system/characters/character-slice-walk-back-v1.png` | `visual-system/characters/character-slice-walk-back-v1-chroma-src.png` |
Preview board:
- `visual-system/characters/character-transparent-slices-preview-v1.png`
## Execution Mode
`gpt-image-2` Skill mode check:
```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 was not enabled.
- Host image generation was used as Mode B.
- Each slice was generated separately.
- The built-in image tool does not expose a direct output-path argument; generated defaults were copied into the project.
- The built-in image tool also does not expose native transparent-background control, so each asset was generated on a flat green chroma-key background and converted locally to alpha PNG.
## Generation Source Mapping
Default host-generated source files were copied as follows:
| Slice | Default source file |
| --- | --- |
| Front | `C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_0cdcfc2a4d6685cc016a3a33d85a548191ace8cb7e4caa0623.png` |
| Side | `C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_0cdcfc2a4d6685cc016a3a341539308191833e4f10d980865e.png` |
| Back | `C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_0cdcfc2a4d6685cc016a3a34912710819196953af31c806bb2.png` |
| Walk side | `C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_0cdcfc2a4d6685cc016a3a34c91b3c819182e18394180e4000.png` |
| Walk back | `C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_0cdcfc2a4d6685cc016a3a3503e1d481918e8786806eb9a450.png` |
## Transparency Validation
Local alpha conversion used:
```text
C:\Users\wangq\.codex\skills\.system\imagegen\scripts\remove_chroma_key.py
```
Python environment:
```text
C:\Users\wangq\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe
```
Validation result:
| File | Mode | Size | Transparent pixels | Partial pixels | Corner alpha |
| --- | --- | --- | ---: | ---: | --- |
| `character-slice-front-v1.png` | RGBA | 864x1821 | 959873 | 9220 | `[0, 0, 0, 0]` |
| `character-slice-side-v1.png` | RGBA | 864x1821 | 1041950 | 8430 | `[0, 0, 0, 0]` |
| `character-slice-back-v1.png` | RGBA | 864x1821 | 983848 | 8599 | `[0, 0, 0, 0]` |
| `character-slice-walk-side-v1.png` | RGBA | 1024x1536 | 1195863 | 7495 | `[0, 0, 0, 0]` |
| `character-slice-walk-back-v1.png` | RGBA | 864x1821 | 1044861 | 8060 | `[0, 0, 0, 0]` |
Validation interpretation:
- All five final files have an alpha channel.
- All four corners are fully transparent.
- Partial alpha pixels exist around edges, which is expected from soft matte extraction.
## Visual Review
Local preview file:
```text
visual-system/characters/character-transparent-slices-preview-v1.png
```
Observed strengths:
- All five figures are full body and fully inside the canvas.
- The long dark coat, backpack, old boots, longer hair, glasses, and fuller beard system remains coherent enough for this first slice batch.
- The walking side pose is upright and does not repeat the rejected v1 hunched walking issue.
- The walking back pose reads as continuing forward rather than collapsed.
- Back-view identity is usable: backpack, long coat, hair outline, and boot stride are clear.
Observed risks:
- These were generated by host prompt-only Mode B. The local v2 anchor image and source photo were not attached as binary image inputs to the image tool.
- Therefore, same-person fidelity is based on the approved textual identity lock plus generated-context continuity, not on a strict image-reference pipeline.
- The front / side / back likeness is coherent at the character-system level, but should still be treated as a candidate set, not a final locked production asset set.
- The side standing slice has a naturally forward profile and heavy coat; it should be checked by the user against the "not hunched" requirement.
## Checklist
| Check | Result | Notes |
| --- | --- | --- |
| Five requested slices exist | Pass | Front, side, back, walk-side, walk-back generated. |
| Final files are alpha PNG | Pass | RGBA mode; transparent corners confirmed. |
| Full body inside canvas | Pass | No obvious crop in local preview. |
| Same character system | Pass with note | Coherent coat / backpack / boots / hair / beard system; not strict binary-reference identity. |
| Walking side posture | Pass | Upright chest and straighter spine; not the rejected v1 hunch. |
| Walking back posture | Pass | Continues forward without collapsed shoulders. |
| Back-view recognition | Pass | Backpack, coat, hair outline, and boots are stable. |
| Avoid fashion / hero drift | Pass | Practical road-worn silhouette, not fashion editorial. |
| Transparency edge quality | Pass with note | Soft alpha edge present; user should inspect at final compositing scale. |
## Recommendation
Do not use this slice set for production prompts.
Treat it as a failed identity-preservation test:
1. Keep the files as failed-trial evidence.
2. Do not delete them unless explicitly requested.
3. Do not promote this transparent-slice workflow into reusable rules.
4. Repair the slice workflow before generating more character execution assets.
Root cause assessment:
- The host tool produced five separate prompt-only generations.
- The accepted v2 anchor and source photo were recorded as references, but were not attached as strict binary image inputs.
- Therefore the model regenerated a similar "road traveler type" instead of preserving the accepted v2 person.
Required process change:
- Transparent character slices must be repaired one at a time.
- The next attempt should be reference-bound or crop-derived from the accepted v2 board, not independent text-only generation.
- The first repaired slice should be `front`, because face / hair / beard / glasses identity drift is easiest to judge there.

Binary file not shown.

After

Width:  |  Height:  |  Size: 614 KiB

View File

@ -0,0 +1,98 @@
# Character Transparent Slices V2 From Anchor Review
## Status
- Review status: accepted by user.
- Scope: repaired transparent slice set derived from the accepted v2 character anchor board.
- Repair reason: the first generated v1 slice set drifted away from the accepted v2 identity.
- Repair strategy: crop each required pose from `character-anchor-v2-codex-posture-test.png` and remove the local board background.
- Next gated action: proceed to the common style anchor board.
## Source
Accepted anchor board:
```text
visual-system/characters/character-anchor-v2-codex-posture-test.png
```
Preview board:
```text
visual-system/characters/character-transparent-slices-v2-from-anchor-preview.png
```
## Final Alpha PNG Assets
| Slice | Final alpha PNG | Source crop |
| --- | --- | --- |
| Front | `visual-system/characters/character-slice-front-v2-from-anchor.png` | `visual-system/characters/character-anchor-v2-front-reference-crop-tight.png` |
| Side | `visual-system/characters/character-slice-side-v2-from-anchor.png` | `visual-system/characters/character-anchor-v2-side-reference-crop-tight.png` |
| Back | `visual-system/characters/character-slice-back-v2-from-anchor.png` | `visual-system/characters/character-anchor-v2-back-reference-crop-tight.png` |
| Walk side | `visual-system/characters/character-slice-walk-side-v2-from-anchor.png` | `visual-system/characters/character-anchor-v2-walk-side-reference-crop-tight.png` |
| Walk back | `visual-system/characters/character-slice-walk-back-v2-from-anchor.png` | `visual-system/characters/character-anchor-v2-walk-back-reference-crop-tight.png` |
## Crop Boxes
Crop boxes are from the accepted v2 board in pixel coordinates:
| Slice | Crop box |
| --- | --- |
| Front | `(20, 104, 264, 835)` |
| Side | `(276, 104, 474, 835)` |
| Back | `(485, 104, 713, 835)` |
| Walk side | `(948, 160, 1212, 835)` |
| Walk back | `(1228, 120, 1412, 835)` |
## Local Processing Method
This repair did not use new image generation.
Method:
1. Crop each pose from the accepted v2 anchor board.
2. Estimate the local neutral board background from crop borders.
3. Remove border-connected light background.
4. For walking crops, keep the largest connected foreground component to remove adjacent panel bleed.
5. Apply a soft alpha matte.
6. Save as alpha PNG.
7. Build a checkerboard preview for human review.
Processing environment:
```text
C:\Users\wangq\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe
```
## Validation
| Slice | Mode | Size | Transparent pixels | Partial pixels | Opaque pixels | Corner alpha |
| --- | --- | --- | ---: | ---: | ---: | --- |
| Front | RGBA | 488x1440 | 247699 | 33986 | 421035 | `[0, 0, 0, 0]` |
| Side | RGBA | 396x1452 | 221077 | 26806 | 327109 | `[0, 0, 0, 0]` |
| Back | RGBA | 456x1442 | 220243 | 32337 | 404972 | `[0, 0, 0, 0]` |
| Walk side | RGBA | 470x1158 | 273011 | 31410 | 239839 | `[0, 0, 0, 0]` |
| Walk back | RGBA | 368x1218 | 161412 | 20482 | 266330 | `[0, 0, 0, 0]` |
## Review Notes
Strengths:
- Identity drift is avoided because every slice is derived directly from the accepted v2 board.
- Front, side, back, walk-side, and walk-back all share the same v2 figure system.
- The walk-side slice preserves the corrected upright walking posture from v2.
- The walk-back slice no longer includes the stray neighboring-panel boot after connected-component cleanup.
- All five final files have alpha channels and transparent corners.
Known limitations:
- Resolution is limited by the 16:9 anchor board cell size.
- The side slice inherits the v2 board's panel crop and keeps the backpack close to the right edge.
- Edge quality is local matte extraction quality, not native transparent rendering.
- These are execution references for small MV figures, not high-resolution hero assets.
## Recommendation
Use this v2-from-anchor set if identity fidelity is the priority for small-figure MV shots.
If user accepts this set, the next project step can move to the common style anchor board. If any slice needs repair, repair only that slice and keep the v2-derived method.

View File

@ -0,0 +1,68 @@
# Style Anchor Board Review V1
## Status
- Document status: user accepted.
- Project: `在路上`.
- Board HTML: `visual-system/style/style-anchor-board-v1.html`.
- Board PNG: `visual-system/style/style-anchor-board-v1.png`.
- Render size: `1920x1080`.
- Render method: deterministic HTML/CSS layout captured with local browser rendering.
- Review result: accepted as the common style anchor board.
## Source Images Used
| Anchor | Image | Status |
| --- | --- | --- |
| A | `intake/imgs/A.风景主导型蓝图.png` | accepted source sample |
| B | `intake/imgs/B.高位观察型蓝图.png` | accepted source sample |
| C | `visual-system/style/style-anchor-c-repair-v1.png` | accepted repaired C sample |
| D | `intake/imgs/D.夜路篝火型蓝图.png` | accepted source sample |
Original C was not used as the board's C sample:
```text
intake/imgs/C.泥泞里的星空蓝图.png
```
## Local Inspection
Pass:
- A/B/C/D all render in the 2x2 sample grid.
- C uses the accepted repaired muddy starlight image.
- Chinese labels are rendered as real HTML text, not generated image text.
- The right rules column is readable.
- The bottom review standard is readable.
- The board is 16:9 and exported as `1920x1080`.
Watch points for user review:
- A remains warmer because the accepted A source has sun at the horizon; this is already part of the accepted source image, not a board-rendering error.
- The board is intentionally utilitarian and reference-oriented, not poster-like.
## Acceptance Criteria Review
| Criterion | Assessment | Notes |
| --- | --- | --- |
| A/B/C/D look like one MV | pass for review | Shared dark board, low-saturation sources, and consistent labels tie them together. |
| First read is environment/world, not character poster | pass | The layout prioritizes four landscape/motif samples and rules. |
| Chinese text exact and readable | pass | Text is deterministic HTML text. |
| C uses repaired sample | pass | Uses `style-anchor-c-repair-v1.png`. |
| Warmth remains restrained | mostly pass | D warmth is local; A source has horizon warmth but stays within the accepted A image. |
| Rules column guides later prompts | pass | Color, light, composition, texture, and avoid rules are present. |
| Usable for five-shot test setup | pass for review | It maps directly to S-01, S-10, S-46, S-47, and S-51 anchors. |
## Decision
User accepted:
```text
visual-system/style/style-anchor-board-v1.png
```
Next gated step:
```text
five-shot trial plan/spec
```

View File

@ -0,0 +1,320 @@
# Style Anchor Board Spec V1
## Status
- Document status: user approved and rendered.
- Execution status: rendered once as deterministic HTML/PNG; output accepted by user.
- Project: `在路上`.
- Purpose: define the common style anchor board layout using accepted A/B/C/D visual samples.
- Output target after approval: deterministic layout artifact, not AI-generated text inside an image.
Rendered outputs:
```text
visual-system/style/style-anchor-board-v1.html
visual-system/style/style-anchor-board-v1.png
```
## Why This Is Not An Image-Generation Prompt
The common style anchor board must contain exact Chinese labels and review rules.
Therefore this board should be built as a deterministic layout artifact:
- source images are inserted as image assets;
- Chinese labels are rendered by HTML/CSS or another local layout method;
- no generated model text is used as the source of truth;
- the board can be revised without regenerating the visual samples.
Recommended implementation after approval:
```text
visual-system/style/style-anchor-board-v1.html
visual-system/style/style-anchor-board-v1.png
```
## Source Files Actually Used
Primary sources:
- `visual-system/style/style-anchor-brief-v1.md`
- `visual-system/style/style-anchor-c-repair-review-v1.md`
- `visual-system/visual-system.md`
- `intake/阶段四-风格锚点板页面结构建议稿.md`
Execution control:
- `project.md`
- `execution-plan.md`
## Source Images
All four source images are `1672x941`, approximately 16:9.
| Anchor | Image | Role |
| --- | --- | --- |
| A | `intake/imgs/A.风景主导型蓝图.png` | Accepted A sample: landscape-led muddy road. |
| B | `intake/imgs/B.高位观察型蓝图.png` | Accepted B sample: high-angle city-edge observation. |
| C | `visual-system/style/style-anchor-c-repair-v1.png` | Accepted repaired C sample: muddy starlight. |
| D | `intake/imgs/D.夜路篝火型蓝图.png` | Accepted D sample: restrained night-road fire. |
Do not use the original C blueprint as the final C sample:
```text
intake/imgs/C.泥泞里的星空蓝图.png
```
It remains a problem reference only.
## Board Format
Canvas:
- 16:9 horizontal.
- Recommended render size: `1920x1080`.
- Background: dark neutral coal gray, not pure black.
- Overall mood: utilitarian film reference board, not a poster or marketing page.
Background palette:
- page background: coal gray / dark warm gray;
- panel surfaces: slightly lighter dark gray;
- rules text: off-white / muted gray;
- accent: restrained warm orange only for small labels or D/fire references;
- avoid bright blue/purple/cyber palette.
## Layout Structure
Use one MVP page.
Page areas:
1. Top definition band.
2. Left main sample grid.
3. Right compact rules column.
4. Bottom review standard band.
Recommended proportions:
| Area | Approximate share | Notes |
| --- | --- | --- |
| Top band | 14% height | Title, style definition, composition rule. |
| Main sample grid | 68% width, 72% height | A/B/C/D in a 2x2 grid. |
| Right rules column | 26% width, 72% height | Color, light, composition, texture, avoid drift. |
| Bottom band | 10% height | One-line review standard and short review questions. |
## Top Definition Band
Title:
```text
《在路上》MV 风格锚点板
```
Subtitle:
```text
Style Anchor BoardLandscape Narrative Road Film
```
Style definition:
```text
现实纪实质感 + 克制的诗性超现实 + 公路纪录片式风景叙事
```
Composition rule:
```text
世界比人更大,路比人更长,人只是持续前行的坐标
```
## Sample Grid
Use a 2x2 image grid on the left.
Image behavior:
- use each image as an inserted asset;
- crop with `object-fit: cover`;
- preserve each sample's main subject;
- do not apply strong filters;
- keep minor uniform dark overlay only if needed for labels;
- labels must not cover the important subject area.
### A Cell
Title:
```text
A清晨泥泞旷野
```
Function:
```text
风景主导|世界先于人出现
```
Avoid label:
```text
不要旅游片 / 英雄背影
```
### B Cell
Title:
```text
B高位观察
```
Function:
```text
城市边缘|系统里的小人物
```
Avoid label:
```text
不要城市宣传 / 科技感
```
### C Cell
Title:
```text
C泥泞里的星空
```
Function:
```text
灵魂意象|低处看见宇宙
```
Status tag:
```text
修正版已通过
```
Avoid label:
```text
不要日出 / 魔法 / 鞋靴广告
```
### D Cell
Title:
```text
D夜路小火
```
Function:
```text
结尾温度|远方也有人在走
```
Avoid label:
```text
不要露营 / 聚会 / 胜利
```
## Right Rules Column
Keep this column compact and readable.
### 色彩系统
Text:
```text
冷灰 / 土褐 / 暗卡其 / 煤黑 / 湿地暗蓝灰
暖色只作为情绪信号
```
### 光线系统
Text:
```text
自然冷光、湿冷城市边缘、暗夜深度、小范围火光
C 用泥水星点,不用日出日落
```
### 构图系统
Text:
```text
环境优先,人物后置
常规人物约 1/8-1/5大远景可更小
```
### 质感系统
Text:
```text
泥要湿,路要旧,城市要冷硬,火要小
诗性来自现实质感,不来自炫光特效
```
### 禁止跑偏
Text:
```text
人物写真 / 旅行广告 / 城市宣传 / 赛博科技 / 露营聚会 / 胜利海报
```
## Bottom Review Band
One-line review standard:
```text
第一眼看到的应该是路、世界、泥、夜色和火光;人物只是其中继续前行的坐标。
```
Short review questions:
```text
像同一支 MV 吗?人物是否过大?诗性是否来自现实质感?是否仍然在继续走?
```
## Acceptance Criteria
The rendered board passes only if:
1. A/B/C/D look like one MV, not four unrelated projects.
2. The first read is environment and road-film world, not a character poster.
3. Chinese text is exact, readable, and not model-generated.
4. C uses `style-anchor-c-repair-v1.png`, not the original warm C blueprint.
5. Warmth remains local and restrained, mainly belonging to D.
6. The rules column is compact enough to guide later shot prompts.
7. The board is usable as a visual dictionary for S-01, S-10, S-46, S-47, and S-51.
## Next Gated Action
This spec has been approved and rendered as:
```text
visual-system/style/style-anchor-board-v1.html
visual-system/style/style-anchor-board-v1.png
```
Review file:
```text
visual-system/style/style-anchor-board-review-v1.md
```
The rendered style anchor board has been reviewed and accepted. Next work should start with a five-shot trial plan/spec before any shot image generation.

View File

@ -0,0 +1,385 @@
<!doctype html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>《在路上》MV 风格锚点板</title>
<style>
:root {
--bg: #171716;
--panel: #222220;
--panel-2: #2b2a27;
--line: #3a3934;
--text: #ece8dd;
--muted: #b6b0a4;
--dim: #8d877d;
--accent: #c88745;
--cold: #8fa2aa;
--danger: #d7b179;
}
* {
box-sizing: border-box;
}
html,
body {
margin: 0;
width: 100%;
min-height: 100%;
background: var(--bg);
font-family: "Microsoft YaHei", "Noto Sans CJK SC", "PingFang SC", "Segoe UI", sans-serif;
color: var(--text);
}
body {
display: grid;
place-items: start center;
}
.board {
width: 1920px;
height: 1080px;
padding: 28px;
display: grid;
grid-template-rows: 132px 770px 88px;
gap: 18px;
overflow: hidden;
background:
linear-gradient(135deg, rgba(255, 255, 255, 0.035), rgba(255, 255, 255, 0) 36%),
radial-gradient(circle at 80% 14%, rgba(199, 135, 69, 0.10), transparent 25%),
var(--bg);
}
.top {
border: 1px solid var(--line);
background: rgba(34, 34, 32, 0.86);
display: grid;
grid-template-columns: 1fr auto;
align-items: center;
padding: 22px 28px;
}
.title {
display: flex;
flex-direction: column;
gap: 10px;
min-width: 0;
}
h1 {
margin: 0;
font-size: 44px;
line-height: 1;
font-weight: 700;
letter-spacing: 0;
}
.subtitle {
margin: 0;
color: var(--muted);
font-size: 20px;
line-height: 1.2;
letter-spacing: 0;
}
.principles {
display: grid;
gap: 10px;
text-align: right;
max-width: 890px;
min-width: 760px;
font-size: 23px;
line-height: 1.22;
font-weight: 600;
color: var(--text);
}
.principles span:last-child {
color: var(--cold);
}
.main {
display: grid;
grid-template-columns: 1340px 502px;
gap: 22px;
min-height: 0;
}
.samples {
display: grid;
grid-template-columns: repeat(2, 1fr);
grid-template-rows: repeat(2, 1fr);
gap: 18px;
min-height: 0;
}
.sample {
border: 1px solid var(--line);
background: var(--panel);
display: grid;
grid-template-rows: 272px 1fr;
overflow: hidden;
min-width: 0;
min-height: 0;
}
.image-wrap {
position: relative;
min-height: 0;
overflow: hidden;
background: #111;
}
.image-wrap img {
width: 100%;
height: 100%;
object-fit: cover;
display: block;
}
.anchor-mark {
position: absolute;
top: 14px;
left: 14px;
padding: 6px 10px;
border: 1px solid rgba(236, 232, 221, 0.24);
background: rgba(17, 17, 16, 0.70);
color: var(--text);
font-size: 18px;
line-height: 1;
font-weight: 700;
}
.status {
position: absolute;
top: 14px;
right: 14px;
padding: 6px 10px;
border: 1px solid rgba(199, 135, 69, 0.48);
background: rgba(37, 28, 22, 0.76);
color: var(--danger);
font-size: 16px;
line-height: 1;
font-weight: 700;
}
.sample-text {
padding: 12px 16px 11px;
display: grid;
grid-template-columns: 1fr;
align-content: center;
gap: 4px;
min-width: 0;
}
.sample h2 {
margin: 0;
font-size: 24px;
line-height: 1.1;
letter-spacing: 0;
}
.function {
margin: 0;
color: var(--muted);
font-size: 16px;
line-height: 1.2;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.avoid {
margin: 0;
color: var(--accent);
font-size: 15px;
line-height: 1.2;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
.rules {
border: 1px solid var(--line);
background: rgba(34, 34, 32, 0.90);
padding: 18px;
display: grid;
grid-template-rows: repeat(5, 1fr);
gap: 13px;
min-height: 0;
}
.rule {
border: 1px solid rgba(58, 57, 52, 0.92);
background: rgba(43, 42, 39, 0.86);
padding: 16px 17px;
display: grid;
align-content: center;
gap: 9px;
min-height: 0;
}
.rule h3 {
margin: 0;
font-size: 22px;
line-height: 1.1;
letter-spacing: 0;
color: var(--text);
}
.rule p {
margin: 0;
color: var(--muted);
font-size: 17px;
line-height: 1.45;
letter-spacing: 0;
}
.rule strong {
color: var(--accent);
font-weight: 700;
}
.bottom {
border: 1px solid var(--line);
background: rgba(34, 34, 32, 0.86);
display: grid;
grid-template-columns: 1.18fr 1fr;
align-items: center;
gap: 28px;
padding: 16px 24px;
}
.review-standard {
margin: 0;
font-size: 25px;
line-height: 1.25;
font-weight: 700;
color: var(--text);
}
.review-standard span {
color: var(--accent);
}
.questions {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
gap: 8px 14px;
margin: 0;
padding: 0;
list-style: none;
color: var(--muted);
font-size: 17px;
line-height: 1.25;
}
.questions li::before {
content: "· ";
color: var(--accent);
font-weight: 700;
}
</style>
</head>
<body>
<main class="board" aria-label="《在路上》MV 风格锚点板">
<header class="top">
<div class="title">
<h1>《在路上》MV 风格锚点板</h1>
<p class="subtitle">Style Anchor BoardLandscape Narrative Road Film</p>
</div>
<div class="principles">
<span>现实纪实质感 + 克制的诗性超现实 + 公路纪录片式风景叙事</span>
<span>世界比人更大,路比人更长,人只是持续前行的坐标</span>
</div>
</header>
<section class="main">
<div class="samples">
<article class="sample">
<div class="image-wrap">
<img src="../../intake/imgs/A.风景主导型蓝图.png" alt="A 清晨泥泞旷野">
<div class="anchor-mark">A</div>
</div>
<div class="sample-text">
<h2>A清晨泥泞旷野</h2>
<p class="function">风景主导|世界先于人出现</p>
<p class="avoid">不要旅游片 / 英雄背影</p>
</div>
</article>
<article class="sample">
<div class="image-wrap">
<img src="../../intake/imgs/B.高位观察型蓝图.png" alt="B 高位观察">
<div class="anchor-mark">B</div>
</div>
<div class="sample-text">
<h2>B高位观察</h2>
<p class="function">城市边缘|系统里的小人物</p>
<p class="avoid">不要城市宣传 / 科技感</p>
</div>
</article>
<article class="sample">
<div class="image-wrap">
<img src="style-anchor-c-repair-v1.png" alt="C 泥泞里的星空">
<div class="anchor-mark">C</div>
<div class="status">修正版已通过</div>
</div>
<div class="sample-text">
<h2>C泥泞里的星空</h2>
<p class="function">灵魂意象|低处看见宇宙</p>
<p class="avoid">不要日出 / 魔法 / 鞋靴广告</p>
</div>
</article>
<article class="sample">
<div class="image-wrap">
<img src="../../intake/imgs/D.夜路篝火型蓝图.png" alt="D 夜路小火">
<div class="anchor-mark">D</div>
</div>
<div class="sample-text">
<h2>D夜路小火</h2>
<p class="function">结尾温度|远方也有人在走</p>
<p class="avoid">不要露营 / 聚会 / 胜利</p>
</div>
</article>
</div>
<aside class="rules" aria-label="风格规则区">
<section class="rule">
<h3>色彩系统</h3>
<p>冷灰 / 土褐 / 暗卡其 / 煤黑 / 湿地暗蓝灰<br><strong>暖色只作为情绪信号</strong></p>
</section>
<section class="rule">
<h3>光线系统</h3>
<p>自然冷光、湿冷城市边缘、暗夜深度、小范围火光<br>C 用泥水星点,不用日出日落</p>
</section>
<section class="rule">
<h3>构图系统</h3>
<p>环境优先,人物后置<br>常规人物约 1/8-1/5大远景可更小</p>
</section>
<section class="rule">
<h3>质感系统</h3>
<p>泥要湿,路要旧,城市要冷硬,火要小<br>诗性来自现实质感,不来自炫光特效</p>
</section>
<section class="rule">
<h3>禁止跑偏</h3>
<p>人物写真 / 旅行广告 / 城市宣传 / 赛博科技 / 露营聚会 / 胜利海报</p>
</section>
</aside>
</section>
<footer class="bottom">
<p class="review-standard">第一眼看到的应该是<span>路、世界、泥、夜色和火光</span>;人物只是其中继续前行的坐标。</p>
<ul class="questions">
<li>像同一支 MV 吗?</li>
<li>人物是否过大?</li>
<li>诗性是否来自现实质感?</li>
<li>是否仍然在继续走?</li>
</ul>
</footer>
</main>
</body>
</html>

View File

@ -0,0 +1,466 @@
# Style Anchor Brief V1
## Status
- Document status: user approved; C repair candidate accepted.
- Execution status: brief used as source for C repair prompt/spec and accepted C sample.
- Project: `在路上`.
- Source basis: accepted visual system, style anchor trial plan, and A/B/C/D blueprint images.
- Next gated action: review `style-anchor-board-spec-v1.md` before rendering the common style anchor board.
## Purpose
This brief defines the project-specific common style anchor requirements for `在路上`.
It is not a final image prompt.
It should answer:
> What kind of image belongs to this MV, and what kind of image is good-looking but wrong for this MV?
The style anchor must keep later wilderness, city-edge, muddy-puddle, night-road, and firelight shots inside one coherent visual world.
## Source Files Actually Used
Primary style sources:
- `visual-system/style/style-anchor-trial-plan.md`
- `visual-system/visual-system.md`
- `intake/阶段四-通用表达与视觉系统设计.md`
- `intake/阶段四-风格锚点板页面结构建议稿.md`
Execution control:
- `project.md`
- `execution-plan.md`
Source images:
- `intake/imgs/A.风景主导型蓝图.png`
- `intake/imgs/B.高位观察型蓝图.png`
- `intake/imgs/C.泥泞里的星空蓝图.png`
- `intake/imgs/D.夜路篝火型蓝图.png`
Local inspection aid:
- `visual-system/style/style-blueprints-contactsheet.png`
## Current Source Image Roles
| Anchor | Source image | Status | Use |
| --- | --- | --- | --- |
| A | `intake/imgs/A.风景主导型蓝图.png` | usable base | Main landscape-led road composition. |
| B | `intake/imgs/B.高位观察型蓝图.png` | usable base | High-angle city-edge observation. |
| C | `visual-system/style/style-anchor-c-repair-v1.png` | accepted repair sample | Final C visual sample for the common style anchor board. |
| C original | `intake/imgs/C.泥泞里的星空蓝图.png` | problem reference | Retain only as earlier composition/problem reference. |
| D | `intake/imgs/D.夜路篝火型蓝图.png` | usable base | Restrained night-road fire warmth. |
Important distinction:
- A/B/D can be used as style samples in the eventual board.
- C has been rebuilt and accepted as `visual-system/style/style-anchor-c-repair-v1.png`.
## Core Style Definition
The MV visual style is:
> Real documentary texture + restrained poetic surrealism + landscape-led road-film composition.
Chinese working definition:
> 现实纪实质感 + 克制的诗性超现实 + 公路纪录片式风景叙事。
Core composition rule:
> The world is larger than the person, the road is longer than the person, and the traveler is only the coordinate that keeps moving.
Chinese working rule:
> 世界比人更大,路比人更长,人只是持续前行的坐标。
The emotional center is not victory. It is continuation.
## Style Anchor A: Landscape-Led Road
Working title:
> A清晨泥泞旷野世界先于人出现
Function:
- main composition standard;
- proves world-before-person;
- establishes the road-film grammar for the whole MV.
Current source:
```text
intake/imgs/A.风景主导型蓝图.png
```
Preserve:
- long road;
- large world;
- small person;
- mud / frost / rough terrain;
- cold morning or pre-dawn feeling;
- low saturation;
- loneliness without collapse.
Avoid:
- travel advertisement;
- scenic tourism image;
- hero backshot;
- large portrait subject;
- polished inspirational poster.
Use in later tests:
- `S-01` opening landscape;
- any shot where the first impression must be road / world / continuation.
## Style Anchor B: High-Angle City Edge
Working title:
> B高位观察系统边缘里的小人物
Function:
- city-edge and system-pressure style;
- observation rather than portrait;
- proves that urban shots still belong to the same road-film world.
Current source:
```text
intake/imgs/B.高位观察型蓝图.png
```
Preserve:
- high-angle observation;
- city edge, not city center;
- wet ground;
- rough terrain;
- steel / concrete / distant skyline pressure;
- small traveler;
- documentary distance.
Avoid:
- city promotion image;
- clean commercial skyline;
- futuristic UI / code / neon / cyber city;
- tech-product aesthetic;
- ordinary tourism aerial shot.
Use in later tests:
- `S-10` steel canyon / system-pressure shot.
## Style Anchor C: Muddy Starlight
Working title:
> C泥泞里的星空低处看见宇宙
Function:
- soul image of the MV;
- must prove that poetry comes from real mud, not from fantasy effects;
- must connect low place and high place through broken starlight reflection.
Original source:
```text
intake/imgs/C.泥泞里的星空蓝图.png
```
Current status:
- repaired and accepted as final C sample for the common style anchor board;
- original C source remains only as a problem reference and composition hint.
Accepted repair sample:
```text
visual-system/style/style-anchor-c-repair-v1.png
```
What can be retained from the current C blueprint:
- low mud-level perspective;
- real muddy texture;
- puddle as main visual subject;
- boot / body element only at the edge.
Problems to fix:
- too close to sunrise / sunset reflection;
- too warm and bright;
- sky / star reflection is not broken and visible enough;
- the spiritual function is weaker than required.
Required rebuilt C direction:
- dark night or pre-dawn;
- muddy puddle is the visual subject;
- visible broken star reflection in the water;
- real mud around the puddle;
- low-place-sees-high-place feeling;
- old boot or traveler element only at the edge, under about 15% of the image;
- restrained, quiet, documentary-real, not fantasy.
Strictly avoid:
- sunrise;
- sunset;
- broad warm horizon glow;
- pretty reflection only;
- fantasy magic;
- glowing portal / cosmic effects;
- shoe advertisement framing;
- only mud and no stars;
- only stars and no mud.
Use in later tests:
- `S-46` muddy starlight.
Gate:
- C repair prompt/spec has been completed and accepted before final common style board assembly.
## Style Anchor D: Night Road Fire
Working title:
> D夜路小火远方也有人在走
Function:
- ending warmth anchor;
- confirms the presence of other people without turning into reunion or victory;
- defines restrained firelight logic for late shots.
Current source:
```text
intake/imgs/D.夜路篝火型蓝图.png
```
Preserve:
- dark road;
- small fire;
- local warm-orange light;
- distant faint fire points or lights;
- restrained night depth;
- loneliness with connection.
Avoid:
- camping advertisement;
- campfire party;
- group reunion;
- victory image;
- outdoor lifestyle promotion;
- large theatrical firelight.
Use in later tests:
- `S-47` restrained near-fire transition;
- `S-51` final wide with distant fire.
## Color System
Base palette:
- cold gray;
- earth brown;
- dark khaki;
- coal black;
- wet dark blue-gray.
Emotional colors:
- small warm-orange fire;
- weak pre-dawn silver-blue;
- very small pale-gold edge only if needed.
Rules:
- low saturation most of the time;
- warmth should be a signal, not the general palette;
- dark scenes must retain depth;
- C must stay away from broad warm sunrise / sunset light.
Avoid:
- bright tourism palette;
- high-saturation advertising palette;
- cyber blue / purple;
- sweet warm yellow;
- heavy commercial orange-blue blockbuster grading.
## Light System
Preferred light:
- overcast;
- cold morning;
- thin frost / pre-dawn;
- wet city gray;
- bridge shadow;
- dusk;
- dark night;
- small local firelight.
Rules:
- daylight should feel natural and restrained;
- city edge should feel wet, gray, and cold;
- night should remain dark;
- fire should be local and small;
- muddy starlight should use low reflection and broken star points, not sun.
Avoid:
- bright noon;
- tourist sunlight;
- broad theatrical rim light;
- stage-like night lighting;
- beautiful sunset as shortcut for emotion.
## Composition System
Global rule:
> Environment first, traveler second.
Traveler scale:
- ordinary shots: about 1/8 to 1/5 of the frame;
- final wide or large landscape: about 1/20 to 1/12;
- C muddy starlight: boot / body element under about 15%, if present.
Preferred compositions:
- long horizontal road;
- traveler lower or side-positioned;
- large sky, ground, road, mud, or city-edge space;
- high-angle observation;
- low mud-level view;
- distant fire points;
- wide shot and medium-wide shot.
Avoid:
- centered hero portrait;
- front-face half-body portrait as a default;
- low-angle heroic pose;
- travel blogger backshot;
- campfire gathering center composition;
- shoe closeup as product image.
## Texture System
Real texture anchors:
- mud is wet and heavy;
- puddles are irregular and dirty;
- road is long and worn;
- city edge is cold and hard;
- fire is small and real;
- boots and backpack are old and used.
Poetry should come from:
- low-place reflection;
- wind and empty space;
- small fire in night;
- broken starlight in muddy water;
- the traveler being small inside a larger world.
Avoid:
- over-clean surfaces;
- over-polished cinematic beauty;
- fantasy effects;
- commercial product texture;
- pure dirt / despair without poetic opening.
## Final Style Anchor Board Requirements
The final common style anchor board should be a layout artifact, not a single generated image with embedded text.
Reason:
- exact Chinese labels must be reliable;
- generated text should not carry the source of truth;
- A/B/D already exist as visual sources;
- C must be repaired first.
Recommended board:
- one 16:9 horizontal page;
- dark gray / coal-gray background, not pure black;
- title and two top rules;
- four visual sample cells A/B/C/D;
- C marked as repaired or priority-fix depending on stage;
- right-side compact rules: color, light, composition, texture, avoid drift;
- bottom review rule line.
Minimum content:
1. `《在路上》MV 风格锚点板`;
2. `现实纪实质感 + 克制的诗性超现实 + 公路纪录片式风景叙事`;
3. `世界比人更大,路比人更长,人只是持续前行的坐标`;
4. A/B/C/D samples;
5. color / light / composition / texture rules;
6. C marked as repaired / accepted;
7. one-line review standard.
## One-Line Review Standard
Use this as the bottom rule of the final board:
> 第一眼看到的应该是路、世界、泥、夜色和火光;人物只是其中继续前行的坐标。
## Review Questions
Use these questions after C repair and after final board assembly.
1. Do A/B/C/D look like the same MV, not four separate projects?
2. Does A establish road and world before person?
3. Does B feel like documentary observation at the system edge?
4. Does C truly show muddy starlight, not sunrise or pretty reflection?
5. Does D feel warm but restrained, not camping or reunion?
6. Does the palette stay low-saturation, with warmth only as a signal?
7. Does the board guide later shot prompts, not just look attractive?
## Next Gated Action
The brief has already been used to create:
```text
visual-system/style/style-anchor-c-repair-prompt-v1.md
```
The prompt/spec has produced one accepted C repair sample:
```text
visual-system/style/style-anchor-c-repair-v1.png
visual-system/style/style-anchor-c-repair-review-v1.md
```
Next decision:
- review the common style anchor board specification before rendering the final board.
```text
visual-system/style/style-anchor-board-spec-v1.md
```

View File

@ -0,0 +1,237 @@
# Style Anchor C Repair Prompt V1
## Status
- Document status: user approved for one C repair generation.
- Execution status: used once in Mode B host generation; output accepted by user via `style-anchor-c-repair-review-v1.md`.
- Project: `在路上`.
- Anchor: C泥泞里的星空.
- Purpose: rebuild the C style anchor as a dark muddy starlight image.
- Next gated action: completed; accepted C repair was used in the common style anchor board.
Generated candidate:
```text
visual-system/style/style-anchor-c-repair-v1.png
```
## 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` as the prompt-engineering workflow.
- Garden local generation is not enabled.
- This Codex environment has a host image-generation path, so later execution should be treated as Mode B if the user approves generation.
- Do not call Garden scripts for this step.
## Skill Files Actually 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`
Template adaptation:
- `concept-scene.md` is used for foreground / midground / background / lighting structure.
- `minimalist-mood-scene.md` is used for restraint, negative space, and mood-first control.
- The final target is not epic concept art and not illustration. It should read as a realistic cinematic documentary still.
## Source Files Actually Used
Primary project sources:
- `visual-system/style/style-anchor-brief-v1.md`
- `visual-system/style/style-anchor-trial-plan.md`
- `visual-system/visual-system.md`
- `intake/阶段四-通用表达与视觉系统设计.md`
- `intake/阶段四-风格锚点板页面结构建议稿.md`
Problem reference image:
```text
intake/imgs/C.泥泞里的星空蓝图.png
```
Role:
- problem reference;
- composition hint;
- not accepted target;
- not an edit target unless the execution tool explicitly supports image editing and the user asks for edit mode.
What to retain from the problem reference:
- mud-level camera;
- real muddy road texture;
- puddle as main visual subject;
- old boot or traveler trace only at the edge;
- low place looking upward through reflection.
What to reject from the problem reference:
- sunrise / sunset feeling;
- broad warm horizon glow;
- pretty orange reflection;
- overly bright sky reflection;
- weak or secondary star reflection.
## C Repair Target
The repaired C image must answer:
> 人还在泥里,但他终于在泥里看见了星空。
The image should not feel like escape from mud. It should feel like meaning discovered inside the low place.
Required direction:
- dark night or deep pre-dawn;
- real muddy puddle as the main subject;
- visible broken star reflection in the water;
- real wet mud around the puddle;
- old boot or traveler element only at the edge, under about 15% of the frame;
- quiet and restrained;
- documentary-real with poetic pressure;
- 16:9 horizontal.
## Rendered Prompt
Use the existing C blueprint only as a problem reference and composition hint. Preserve its useful parts: ground-level mud perspective, irregular muddy puddle as the main subject, real wet mud texture, and a small old boot or traveler trace at the edge. Do not preserve its sunrise / sunset warmth, broad orange horizon glow, or pretty warm reflection.
Generate one 16:9 horizontal realistic cinematic documentary still for the `在路上` MV style anchor C: "muddy starlight".
The camera is extremely low, near the muddy ground. The frame is dominated by an irregular muddy puddle in the foreground and middle ground, surrounded by heavy wet mud, small stones, broken shoe prints, dark road grit, and uneven puddle edges. The puddle reflects a dark night or deep pre-dawn sky. The reflected stars are visible and broken: scattered small cold points, slightly fragmented by ripples, dirt, uneven water, and mud. The reflection should feel discovered inside the dirty water, not like a fantasy portal.
The physical world remains real: sticky wet mud, dull earth-brown sludge, coal-black road edges, cold blue-gray night, faint silver-blue sky reflection, low contrast, restrained detail. The image should feel like poetic realism, not fantasy.
A small old walking boot or the edge of the traveler's lower body may appear only at the far left or lower edge of the frame, partially cropped, under about 15% of the image. It should confirm bodily presence and road cost, not become a shoe advertisement or a character portrait. The puddle and broken starlight remain the subject.
Lighting:
- dark night or deep pre-dawn;
- very low ambient light;
- cold silver-blue star reflection;
- no broad warm horizon;
- no visible sun;
- no sunset glow;
- no sunrise glow;
- no large cinematic rim light;
- dark areas retain depth without becoming flat black.
Composition:
- 16:9 horizontal;
- mud and puddle fill most of the frame;
- horizon, if visible, is minimal and dark;
- no face;
- no hero body;
- no centered person;
- no clean landscape beauty shot;
- no text, no labels, no logo, no UI.
Mood:
- quiet;
- low;
- heavy;
- restrained;
- lonely but not hopeless;
- the feeling of "low place sees high place";
- continuation, not victory.
Strictly avoid:
- sunrise;
- sunset;
- bright dawn;
- broad orange / gold horizon light;
- pretty tourism reflection;
- fantasy magic;
- glowing portal;
- cosmic explosion;
- surreal galaxy water that overwhelms the mud;
- clean mirror-like lake;
- beautiful landscape postcard;
- shoe advertisement;
- boot closeup as product shot;
- person as main subject;
- camping or firelight;
- neon / cyberpunk / sci-fi;
- UI, code, symbols, text, labels, watermark;
- only mud and no stars;
- only stars and no mud.
The final image should make the viewer first see real mud and a muddy puddle, then discover broken starlight inside the puddle.
## Optional Reference Handling At Generation Time
If the host image tool supports image references:
- attach `intake/imgs/C.泥泞里的星空蓝图.png`;
- label it as problem reference / composition hint;
- explicitly instruct the model to darken and rebuild the scene, not copy the warm sky.
If the host image tool does not support image references:
- use the rendered prompt as a standalone prompt;
- preserve the same problem-reference analysis in the review file.
## Acceptance Criteria
C repair passes only if:
1. The first impression is muddy puddle and real wet mud.
2. Broken star reflection is clearly visible in the puddle.
3. The image reads as night or deep pre-dawn, not sunrise or sunset.
4. Warm horizon light is absent or extremely minimal.
5. The boot / traveler element, if present, stays peripheral and under about 15%.
6. The result feels documentary-real and restrained, not magical.
7. The image can become the C sample in the final style anchor board.
## Failure Conditions
Reject the generation if any of these happen:
- looks like sunrise or sunset;
- puddle becomes a beautiful warm landscape reflection;
- stars are missing or too weak;
- mud becomes too clean;
- image becomes fantasy / cosmic magic;
- boot becomes a shoe ad;
- traveler becomes the main subject;
- visual style no longer fits A/B/D.
## Review File To Create After Generation
After user approval and generation, created:
```text
visual-system/style/style-anchor-c-repair-review-v1.md
```
That review compares the generated C repair against:
- current C problem reference;
- A/B/D style continuity;
- the acceptance criteria above.

View File

@ -0,0 +1,110 @@
# Style Anchor C Repair Review V1
## Status
- Document status: user accepted C repair candidate.
- Project: `在路上`.
- Anchor: C泥泞里的星空.
- Generated image: `visual-system/style/style-anchor-c-repair-v1.png`.
- Prompt source: `visual-system/style/style-anchor-c-repair-prompt-v1.md`.
- Execution mode: `gpt-image-2` Skill Mode B, host image-generation tool.
- Review result: accepted as the C sample for the common style anchor board.
## Generation Trace
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)"
}
```
Generation path:
- Garden local generation was not enabled.
- The prompt was rendered through the `gpt-image-2` Skill workflow.
- The approved rendered prompt was sent to the host image-generation tool.
- The generated output was copied into the project.
Default host output:
```text
C:\Users\wangq\.codex\generated_images\019ef2f7-e630-7303-a0e8-e5e7a86912fc\ig_07b004f488501211016a3a4256b1388196bdde8e5513f400f5.png
```
Project copy:
```text
visual-system/style/style-anchor-c-repair-v1.png
```
## Inspection Method
- Local visual inspection was performed against the acceptance criteria.
- External image-analysis upload was not used; the attempted external vision analysis was rejected because it would send a project image to a third-party service without explicit user authorization.
## Acceptance Criteria Review
| Criterion | Assessment | Notes |
| --- | --- | --- |
| First impression is muddy puddle and real wet mud | pass | The frame is dominated by wet mud, puddle edges, dark grit, stones, and dirty water. |
| Broken star reflection is clearly visible | pass | Star points are visible in the puddle and are interrupted by mud, stones, and uneven water. |
| Reads as night or deep pre-dawn | pass | The palette is cold blue-gray and dark; it does not read as sunrise or sunset. |
| Warm horizon absent or minimal | pass | No broad orange/gold horizon is visible. |
| Boot/traveler stays peripheral under about 15% | pass | The boot is cropped at the far left and remains secondary to the puddle. |
| Documentary-real and restrained, not magical | mostly pass | The mud is real and grounded; the star reflection is slightly luminous but still acceptable as poetic realism. |
| Can become the C sample in the final board | pass | User accepted this candidate as the new C blueprint. |
## Comparison To Previous C Problem Reference
The generated candidate fixes the main known problem in the previous C blueprint:
- no sunrise or sunset feeling;
- no broad warm horizon glow;
- puddle and mud are primary, not a pretty landscape reflection;
- star reflection is clearer and more central;
- traveler trace remains peripheral.
Remaining watch point:
- The reflected stars are clean and bright in the lower-right puddle area. This is visually effective, but if the board needs a harsher documentary tone, a later version could make the stars fewer, smaller, and more broken.
## A/B/D Continuity Check
This candidate should remain compatible with A/B/D if the final board keeps:
- low saturation;
- documentary texture;
- environment-first composition;
- small human presence;
- warmth reserved for D only.
The current C candidate does not introduce neon, cyber, fantasy portal, camping fire, or hero-person framing.
## Decision
User accepted:
```text
visual-system/style/style-anchor-c-repair-v1.png
```
Next step:
```text
visual-system/style/style-anchor-board-spec-v1.md
```

View File

@ -0,0 +1,191 @@
# Style Anchor Trial Plan
## Status
- Document status: user accepted; superseded by style brief/spec/review artifacts.
- Execution status: planning completed; do not generate images from this file.
- Scope: common style anchor board for `在路上`.
- Next gated action after approval: completed through `style-anchor-brief-v1.md`, `style-anchor-board-spec-v1.md`, and `style-anchor-board-review-v1.md`.
## Purpose
The character anchor answers:
> Is this still the same traveler?
The style anchor answers:
> Do these images still belong to the same MV?
This trial should turn the four existing blueprint images into an execution-ready style system without mixing them with the character-anchor workflow.
## Source Images
Blueprint images:
| Anchor | Source file | Current role |
| --- | --- | --- |
| A | `intake/imgs/A.风景主导型蓝图.png` | Accepted base for landscape-led road composition. |
| B | `intake/imgs/B.高位观察型蓝图.png` | Accepted base for high-angle city-edge observation. |
| C | `intake/imgs/C.泥泞里的星空蓝图.png` | Problem reference; must be rebuilt darker with clearer broken starlight. |
| D | `intake/imgs/D.夜路篝火型蓝图.png` | Accepted base for restrained night-road fire warmth. |
Local contact sheet:
```text
visual-system/style/style-blueprints-contactsheet.png
```
## Source Files Actually Used
Primary project sources:
- `visual-system/visual-system.md`
- `intake/阶段四-通用表达与视觉系统设计.md`
- `intake/阶段四-风格锚点板页面结构建议稿.md`
- `project.md`
- `execution-plan.md`
## Initial Blueprint Assessment
### A: 风景主导型
Usable as a base anchor.
What works:
- long road;
- large world / small person;
- cold landscape-led road-film composition;
- low-saturation earth and gray palette.
Watch risk:
- light is somewhat sunrise-like. It is acceptable for A, but should not infect C.
### B: 高位观察型
Usable as a base anchor.
What works:
- city edge rather than city promotion;
- wet ground and rough terrain;
- person small enough;
- documentary observation feeling.
Watch risk:
- keep it away from clean skyline / tech-city / cyber UI drift in later prompts.
### C: 泥泞里的星空
Do not use as final C anchor.
What works:
- mud and puddle reality are present;
- low-angle puddle composition is directionally right.
Problem:
- too close to sunrise / sunset reflection;
- too warm and bright;
- broken star reflection is not clear enough;
- the spiritual function is not yet strong enough.
Required repair:
- dark night or pre-dawn;
- real muddy puddle as main subject;
- visible broken star reflection;
- low-place-sees-high-place feeling;
- no sunrise, no sunset, no fantasy magic, no shoe advertisement.
### D: 夜路篝火型
Usable as a base anchor.
What works:
- dark road;
- small fire;
- restrained warmth;
- distant faint lights;
- not a camping party or victory scene.
Watch risk:
- later D prompts must preserve solitude and distance, not become a gathering.
## Recommended Advancement
Do not directly make the final style board by simply placing the four current blueprints together.
Recommended sequence:
1. **Style brief**
- Create `style-anchor-brief-v1.md`.
- Record A/B/D as usable base references.
- Record C as a repair target, not an accepted anchor.
- Define the visual rules that the final board must enforce.
2. **C repair prompt/spec**
- Create a Skill-based prompt document for C only.
- Use `gpt-image-2` workflow and record mode, template/reference, source files, and input image roles.
- Generate only after user approval.
3. **C repair generation/review**
- Generate one C repair candidate.
- Review it against the dark muddy starlight criteria.
- If C fails, repair C before moving on.
4. **Style anchor board assembly**
- Use accepted A, B, repaired C, and accepted D.
- Prefer a deterministic board/layout artifact for readable labels and rules.
- Do not rely on image generation to render exact Chinese labels.
5. **Five-shot test package**
- Use the accepted character slices and style anchors in `S-01`, `S-10`, `S-46`, `S-47`, `S-51`.
## Board Construction Recommendation
For the final common style anchor board, prefer a layout/composition artifact rather than a single AI-generated board.
Reason:
- A/B/D already exist as useful references.
- C needs one targeted repair.
- The board needs exact Chinese labels and rules.
- Generated text inside an image is not reliable enough to carry execution rules.
Recommended board form:
- one 16:9 dark-gray board;
- four visual sample cells A/B/C/D;
- right-side compact rule column: color, light, composition, texture, drift avoidance;
- bottom review rule line;
- exact text handled by layout/document layer, not by image generation.
## Candidate Reusable Workflow Notes
Do not promote these as stable Video Workbench knowledge yet, but this trial can test:
1. whether style anchors should be split into accepted base anchors plus repair targets;
2. whether exact labels should be assembled outside image generation;
3. whether C-style soul images should always get a separate repair gate;
4. whether five-shot tests should only start after C is repaired.
## Next Gated Action
After this plan is approved, create:
```text
visual-system/style/style-anchor-brief-v1.md
```
That brief should be the project-facing source for:
- C repair prompt/spec;
- final style anchor board structure;
- later five-shot style references.

Binary file not shown.

After

Width:  |  Height:  |  Size: 994 KiB

View File

@ -0,0 +1,111 @@
# Execution Plan
## Current Medium Branch
- Branch: MV shot-image production for later video assembly.
- Format: 16:9 horizontal.
- Production mode: image assets first; video generation/editing remains manual or semi-manual until explicitly automated.
- Prompt ownership: Codex owns final image prompts; GPT intake is source specification, not final prompt.
## Current Execution Focus
Shot-image production is complete for the current 51-shot table. Next work is assembly / export / closeout when requested.
Immediate focus:
1. Do not dispatch more production image packages unless the user requests append-only repair/retry for named slides.
2. Use direct child sessions for normal production-light packages.
3. Keep review `none` unless the user explicitly asks for review.
4. Use test/audit routing only for repairs, workflow debugging, or explicit investigation.
## Materialization Targets
| Target | Required Output | Status |
| --- | --- | --- |
| Character anchor board | Main 16:9 board on shallow gray-white background | accepted v2 |
| Character transparent slices | Front full body, side full body, back full body, walking side, walking back | accepted v2-from-anchor set |
| Character labels | Short identity, clothing, prop, and boundary labels | pending |
| Style anchor board | 16:9 dark-gray board with A/B/C/D samples | accepted |
| C style retest | Dark muddy puddle / broken star reflection sample | accepted |
| Shot test package | S-01, S-10, S-46, S-47, S-51 | accepted |
## Small-Batch Strategy
Do not generate all 51 shots first.
Round 1 uses five shots because they test the system's biggest risks:
| Shot | Why It Is In Round 1 | Anchor |
| --- | --- | --- |
| S-01 | Opening landscape: proves world-before-person and main A composition. | A |
| S-10 | Steel canyon: proves city pressure without tech/UI drift. | B |
| S-46 | Muddy starlight: proves the soul image and C repair. | C |
| S-47 | Night road fire: proves restrained near-fire transition after C. | D |
| S-51 | Final wide: proves distant fire, no victory, no gathering, person remains small. | D |
Round 1 success means these are true:
- The traveler stays recognizable without becoming a portrait subject.
- A/B/C/D feel like one MV, not four unrelated styles.
- C is no longer sunrise/pretty reflection and has clear muddy starlight.
- D is warm but not camping, gathering, or victory.
- The output can support later prompt batching without rewriting the visual system.
## Current Round
- Round: R2 five-shot trial preparation.
- R0 completed: intake cleaned; project execution files initialized.
- R1 completed so far: v2 main character anchor accepted; identity lock approved for slice generation; five transparent slice candidates generated and rejected due identity drift from v2.
- R1 completed: v2 main character anchor accepted; v2-from-anchor transparent slice set accepted.
- R1 completed: C style retest accepted as `style-anchor-c-repair-v1.png`.
- R1 completed: common style anchor board accepted as `style-anchor-board-v1.png`.
- R2 completed: S-01 generated once and accepted by user.
- R2 completed: user waived intermediate prompt review for S-10; S-10 generated once and accepted by user.
- R2 completed: S-46 generated once and accepted by user.
- R2 completed: S-47 generated once and accepted by user.
- R2 completed: S-51 generated once and accepted by user.
- R2 completed: five-shot visual trial generated and accepted by user.
- R3 character-consistency workflow test completed: `s21-v3`, `s14-v2`, and `s25-v2` generated through the Advisor / visible-reference path and accepted by user. Quality route is usable; duplicate `Agent S-14` remains a historical mechanism defect from this run.
- R3 third-round workflow test completed: `session-04` generated `s33-v2` and `s06-v2` through a clean user-visible child session plus internal one-shot SubAgents. Both images were accepted by user; review files were absent as requested; no duplicate-worker defect was observed in this two-slide scope.
- R4 completed visually with mechanism warnings: clean child session `019ef8cf-4ab1-7b41-877b-979dc25b0a76` generated `s02-v2`, `s03-v2`, and `s04-v2`; user accepted all three images and review files were absent as requested. Mechanism is not a clean pass because brief/packet files were written by slide Agents rather than prewritten by the visible child session; `S-04` also has a worker-launch sequencing warning.
- R5 brief-ownership test completed: clean child session `019ef907-16b7-7a43-9924-227892aa62d3` generated accepted `s07-v2`, `s08-v3`, and `s09-v2` with child-owned brief/packet before worker launch for successful outputs. `s08-v2` remains incomplete transport-failure evidence and was retried append-only as `s08-v3`.
- Package-size trials completed through a user-authorized 4-slide package. `session-07` produced accepted `s11-v2`, `s12-v2`, and `s13-v2` with observed context 157K and elapsed time 30m5s. `session-08` mechanically completed `s15-v2` through `s18-v2`, but `s16-v2` failed visual acceptance because it did not achieve `横向大远景,路从画面一侧切向远方,人物极小` and was too similar to `s15`.
- R6 Phase 1 notification/wakeup test completed and user accepted the image: clean child session `019ef9bc-fe96-75b3-b902-5d5ef95feca3` generated append-only `s16-v3` and sent a callback to parent thread `019ef9b5-cc39-7a42-91b1-f9b0852dc95e`; parent post-processing used local handoff/file evidence without polling the child thread.
- R7 production-light simplification test completed: `session-12` generated `s26-v2`, `s27-v2`, and `s28-v2` with review `none`; user accepted all three images and observed 25m48s / 134K tokens.
- R7 direct-child production-light test completed: `session-13` generated `s29-v2`, `s30-v2`, and `s31-v2` directly without Agent/SubAgent; user accepted all three images and observed 10m32s / 114K tokens. This is now the formal production default.
- Production capacity validation completed: direct child session `019efc24-96a4-7582-bb05-914b82a726d5` generated `s32-v2`, `s34-v2`, `s35-v1`, `s36-v1`, and `s37-v1` without Agent/SubAgent or review files; user accepted all five images. User observed callback at about 152K tokens / 58% context and final usage after post-callback document/check work at about 164K tokens / 63% context.
- 8-slide compression validation completed: direct child session `019efc48-d4af-7972-8646-6d04778dfb2c` generated `s38-v1` through `s45-v1` without Agent/SubAgent or review files; user promoted the package to production-pass by production-stage default. User observed 174K tokens / 67% context / 38m37s elapsed. Ordinary production-light packages may now use up to 8 slides, but child callback must be the final action.
- Final production package completed: direct child session `019efc78-e0f1-7601-aaec-bab4f3e6f99d` generated `s48-v1`, `s49-v1`, and `s50-v1` without Agent/SubAgent or review files; child reported `complete`, `problems: none`, `needs_user: none`; parent verification found expected files present, exact review files absent, and no post-callback child writes.
## Active Batch
No active child production package is running. R7 production-light outputs `s26-v2`, `s27-v2`, `s28-v2`, `s29-v2`, `s30-v2`, and `s31-v2`, capacity-validation outputs `s32-v2`, `s34-v2`, `s35-v1`, `s36-v1`, and `s37-v1`, 8-slide validation outputs `s38-v1` through `s45-v1`, and final production outputs `s48-v1` through `s50-v1` are accepted into production-pass. Direct-child, no-Agent topology remains the current production route for future repair/retry packages.
No single-shot gate is active. The five-shot visual trial is accepted. The character-consistency workflow test is visually accepted for S-21, S-14, S-25, S-33, S-06, S-07, S-08, S-09, S-11, S-12, S-13, S-16/s16-v3, S-20/s20-v3, S-22/s22-v3, S-23/s23-v3, S-24/s24-v2, S-26 through S-32, and S-34 through S-50. R4 images for S-02, S-03, and S-04 are visually accepted but remain a mechanism-warning run because child-session brief ownership did not match the desired boundary. `S-16/s16-v2` remains rejected historical evidence.
Current broad-run issue report:
```text
slides/broad-generation-self-audit-v1.md
```
## Open Decisions
| Decision | Default |
| --- | --- |
| Character source face | Current stage does not use the real face; use a 50-year-old traveler based on the defined character system. |
| Character board size | 16:9 page, shallow gray-white background. |
| Character board scope | MVP can start with front/side/back full body plus half-body state; full version should add walking side/back and prop breakdowns. |
| Style board scope | MVP one-page A/B/C/D board; C should be marked as repaired / accepted. |
| Full shot production | Authorized for production-light. Current default route: named clean user-visible child sessions (`子会话:...`) handle up to 8 ordinary production slides directly, write brief/prompt/image/slide status/handoff, use append-only version scanning with overwrite disallowed, suppress review files, skip Agent/SubAgent, skip packet/return artifacts, skip routine final completeness audit, and callback the parent as the final child action when complete or blocked. Use 1-3 slides for identity-heavy, repair-heavy, core-risk, or context-expensive scopes. MiniMax MCP/external vision remains off unless explicitly authorized. |
## Next Decision
Next decision:
- Shot-image production is complete for the current 51-shot table; there is no remaining not-started production scope.
- Keep callback-only behavior: parent dispatches and exits; child completes all writes/checks/handoff work first, then callbacks parent as the final action. Parent reads local handoff by default and inspects details only on warning/blocked/failed.
- Keep the quality route: `gpt-image-2` Advisor prompt/spec, active style master, active character registry when needed, and visible reference images loaded before generation.
- Keep the production-light topology: the visible child session writes `sNN-vN-brief.md`, `sNN-vN-prompt.md`, `sNN-vN-image.png`, `slides.md` updates, and a compact handoff directly. Agent/SubAgent and packet/return files are opt-in for test/audit, repair, exception, or explicit isolated-slide work.
- Keep append-only retry behavior: incomplete outputs such as `s08-v2` remain historical evidence and retries use the next unused version.
- Keep the write-before version scan: one successful slide/version should have one brief/prompt/image target set, and existing files must not be overwritten without explicit authorization.

View File

@ -0,0 +1,28 @@
# Fix Title Batch Report
- Mode: `artifact`
- Output directory: `C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23`
- Files requested: 9
- Files processed: 9
- Generated: 2026-06-23T13:08:37
| Source | Edits | Requires Review | Heading Map | Plan | Fixed | Report |
| --- | ---: | --- | --- | --- | --- | --- |
| 第一轮策划工作总结.md | 0 | yes | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\第一轮策划工作总结.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\第一轮策划工作总结.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\第一轮策划工作总结.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\第一轮策划工作总结.heading-report.md |
| 阶段三-MV 总纲.md | 77 | no | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段三-MV 总纲.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段三-MV 总纲.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段三-MV 总纲.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段三-MV 总纲.heading-report.md |
| 阶段五-核心单镜.md | 66 | no | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-核心单镜.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-核心单镜.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-核心单镜.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-核心单镜.heading-report.md |
| 阶段五-镜头清单骨架.md | 101 | yes | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-镜头清单骨架.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-镜头清单骨架.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-镜头清单骨架.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段五-镜头清单骨架.heading-report.md |
| 阶段四-人物锚点板文案标注稿.md | 0 | no | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板文案标注稿.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板文案标注稿.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板文案标注稿.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板文案标注稿.heading-report.md |
| 阶段四-人物锚点板策划说明.md | 59 | no | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板策划说明.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板策划说明.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板策划说明.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板策划说明.heading-report.md |
| 阶段四-人物锚点板页面结构建议稿.md | 68 | no | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板页面结构建议稿.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板页面结构建议稿.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板页面结构建议稿.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-人物锚点板页面结构建议稿.heading-report.md |
| 阶段四-通用表达与视觉系统设计.md | 92 | no | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-通用表达与视觉系统设计.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-通用表达与视觉系统设计.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-通用表达与视觉系统设计.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-通用表达与视觉系统设计.heading-report.md |
| 阶段四-风格锚点板页面结构建议稿.md | 97 | no | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-风格锚点板页面结构建议稿.heading-map.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-风格锚点板页面结构建议稿.heading-plan.json | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-风格锚点板页面结构建议稿.fixed.md | C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake-repair\fix-title-2026-06-23\阶段四-风格锚点板页面结构建议稿.heading-report.md |
## Files Requiring Review Before Replacement
- `C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake\第一轮策划工作总结.md`
- No explicit document title is present in the body; the first visible H1 is a peer section, so no heading-only title repair was applied.
- Review before replacing if a single-H1 artifact is required; a human should add or approve a title before demoting peer sections.
- `C:\Users\wangq\Documents\Codex\video-workbench\projects\2026-06-23-在路上\intake\阶段五-镜头清单骨架.md`
- The source contains an appended key-shot artifact beginning at line 392; it is retained as a separate H1 root and flagged instead of silently merged.
- The source contains an appended first-round summary/question block beginning at line 1000; that ambiguous appended block is left unchanged for human review.

View File

@ -0,0 +1,9 @@
# Intake Replacement Notes
- Generated: 2026-06-23
- Originals backed up under `originals-before-replacement/`.
- Seven non-flagged files were replaced with their `*.fixed.md` outputs.
- `第一轮策划工作总结.md`: added filename-based document title and demoted existing headings one level.
- `阶段五-镜头清单骨架.md`: replaced with the repaired shot-list artifact only; appended duplicate key-shot and first-round-summary material remains preserved in `阶段五-核心单镜.md`, `第一轮策划工作总结.md`, and the backup copy.
- No image files or non-Markdown intake files were modified.
- `阶段四-人物锚点板文案标注稿.md`: added filename-based document title and demoted the GPT explanatory heading one level after main-session review.

View File

@ -0,0 +1,231 @@
是的,强哥,**第一轮策划工作可以告一段落了。**
但准确说,它完成的是:
> **MV 前期策划第一轮闭环**
> 不是正式执行准备的全部完成。
这一轮我们已经把最关键的策划问题走通了。
---
# 第一轮已经完成的内容
## 1. 构图方向确认
已经确认:
> **风景主导型构图成立。**
全片不走人物写真,不走主角肖像 MV而是
> 风景叙事片 / 公路纪录片 / 诗性纪实影像。
核心原则也已经定下:
> 世界比人更大,路比人更长,人只是持续前行的坐标。
---
## 2. 四个视觉方向完成定位
| 方向 | 当前结论 | 用途 |
| -------- | ---- | -------------- |
| A 风景主导型 | 成立 | 全片主构图 |
| B 高位观察型 | 构图成立 | 城市边缘、系统压迫、观察视角 |
| C 泥泞里的星空 | 需要重修 | 全片灵魂意象 |
| D 夜路篝火型 | 成立 | 结尾情绪锚点 |
最重要的是C 的问题也已经判断清楚:
> 不是不要 C而是要把 C 修成更暗、更冷、更明确的“泥中星空”。
---
## 3. MV 总纲已经成立
我们已经确定这支 MV 的核心不是“胜利”,而是:
> **继续。**
总叙事也已经成立:
> 一个 50 岁的行者,穿过城市、泥泞、风沙和长夜,在泥泞倒影里看见星空,在远方黑暗里看见火光。
> 他没有抵达终点,但确认自己还在路上,也确认远方还有人在走。
---
## 4. 阶段4 通用表达与视觉系统已经完成
已经建立了四层系统:
1. 人物锚点系统;
2. 场景与画面风格系统;
3. 镜头与构图规则;
4. 灵魂意象与母题系统。
也明确了后续最重要的两个基础资产:
* **人物锚点板**
* **风格锚点板**
---
## 5. 人物锚点板结构已经确定
已经明确人物锚点板不是普通定妆照,而是:
> **角色一致性控制总板。**
它应该包括:
* 正面全身;
* 侧面全身;
* 背面全身;
* 半身状态;
* 行走侧身;
* 行走背影;
* 外套 / 背包 / 靴子拆解;
* 气质边界说明。
背景策略也定了:
> **主板浅灰白纯底,补充透明背景切片。**
---
## 6. 风格锚点板结构已经确定
风格锚点板要解决的是:
> 这些画面是不是同一支 MV。
它的四个核心锚点是:
1. 清晨泥泞旷野;
2. 高位城市边缘;
3. 夜色泥洼星空;
4. 夜路小篝火。
其中 C 是重点修正版。
---
## 7. 镜头清单骨架已经完成
已经整理出 **51 个镜头骨架**,并按段落完成:
* 前奏;
* Section A
* Section B
* Section C
* 主体副歌;
* Guitar solo
* 最后四句;
* Outro。
这已经足够作为下一轮执行规划的母版。
---
## 8. 三个关键单镜已经展开
已经展开:
1. **S-10 钢铁峡谷**
现实压力。
2. **S-46 泥泞里,有星空**
灵魂镜头。
3. **S-51 结尾大远景**
情绪收束。
这三个镜头就是全片三根柱子:
> 人被世界压小。
> 人在泥里看见星。
> 人在远方看见火。
> 所以人继续走。
---
# 第一轮的结论
可以这样判断:
> **策划层第一轮已经完成。**
这支 MV 的方向、结构、视觉母题、人物系统、风格系统、镜头骨架和关键镜头都已经成立。
现在不应该继续无限展开策划。
再展开太多,容易进入“过度前期设计”,反而拖慢后面的执行验证。
---
# 下一轮应该做什么
第二轮不再是“想清楚这支 MV 是什么”,而是进入:
> **执行前资产准备与测试。**
建议下一轮顺序是:
## 1. 制作人物锚点板
先解决:
> 这个行者是谁,后面所有镜头里是不是同一个人。
## 2. 制作风格锚点板
尤其重测:
> C泥泞里的星空。
这是目前唯一没有完全成立的核心意象。
## 3. 把镜头清单交给执行层
由 Codex / 图像执行层开始转成:
* 正式镜头 Prompt
* 图像参考调用;
* 人物一致性策略;
* 风格一致性策略;
* 批量生成任务;
* 文件命名与素材管理。
## 4. 不必一次性做完 51 镜
建议先做一个 **关键镜头测试包**
* S-10 钢铁峡谷;
* S-46 泥泞星空;
* S-51 结尾大远景;
* 再加一个 A 风景主导开场镜;
* 再加一个 D 夜路篝火镜。
先验证五类关键画面能不能统一。
---
# 最终判断
是的,强哥,**第一轮策划到这里可以收住了。**
这一轮已经回答了最重要的问题:
> 这支 MV 到底是什么?
> 它不是什么?
> 它靠什么打动人?
> 它的主构图是什么?
> 它的灵魂意象是什么?
> 它的结尾情绪是什么?
> 后续执行应该守住哪些规则?
答案已经清楚了:
> **《在路上》不是一个中年男人的写真。
> 它是一条路、一身泥、一点星光、几簇远火。
> 人很小,但还在走。**

View File

@ -0,0 +1,511 @@
# 《在路上》MV 总纲 / 情绪结构 V1
## 0. 前期构图测试结论固化
这轮测试已经完成了最关键的判断:
**全片主构图成立。**
这支 MV 可以明确走:
> **风景叙事片 / 公路纪录片 / 诗性纪实影像。**
> 人不是被拍摄的对象,人是世界里的行走坐标。
> 路比人长,世界比人大,火比胜利更重要。
四类构图的定位如下:
| 测试方向 | 结论 | 后续用途 |
| -------- | ----------------- | ----------------------------- |
| A 风景主导型 | 成立 | 全片主构图,占最大比例 |
| B 高位观察型 | 构图成立,脚印弱 | 辅助观察视角,用来表现“一个人在系统边缘穿行” |
| C 泥泞里的星空 | 现实感有,诗性不足,星空倒影不明显 | 需要重做为全片灵魂意象,降低亮度,强化夜色、水洼、破碎星光 |
| D 夜路篝火型 | 成立 | 结尾情绪锚点,远处火光代表“还有人在路上” |
导演判断:
> A 是骨架。
> B 是视角。
> C 是灵魂。
> D 是收束。
---
# 阶段3MV 总纲
## 1. 歌曲核心情绪
这首歌的核心不是“我成功了”。
而是:
> 我狼狈过,失败过,重启过,陷进泥里过。
> 但我还在走。
> 而且我终于发现,远处也有人在走。
所以 MV 的核心情绪是:
**疲惫中的继续,孤独中的确认,泥泞中的星空。**
它不是热血片,也不是励志片。
它更像一个中年行者在漫长路上的自我确认:
> 终点还没到。
> 但路还在。
> 火还在。
> 人也还在。
---
## 2. 总体叙事关系
全片不建议设计成强剧情。
不需要讲一个完整故事,比如“主角从城市逃离,最后找到队伍”。
那样容易变俗,也容易变成鸡血片。
更适合的叙事方式是:
> **一个人,在不同的路上持续前行。**
> 城市、泥泞、风沙、夜色、星空、篝火,像他的内心地貌。
> 他没有抵达一个地方,但完成了一次确认:自己仍在路上,远处也有人在路上。
这是一支 **情绪递进型 MV**,不是剧情说明型 MV。
---
## 3. 歌词情绪线
## 第一段0:00 - 0:32
### 前奏 + “清晨薄霜 / 斑驳行囊 / 你要去哪 / 迎着风沙”
### 情绪功能
建立世界。
先让观众看到路、霜、风、旷野,再看到人。
### 画面方向
大远景。
清晨薄霜,泥泞道路,风从远处压过来。
主角很小,背着旧包,走在画面下方或偏侧。
### 构图调用
主要调用 **A 风景主导型**
### 关键原则
开头不要急着给脸。
第一眼必须是“世界很大”,不是“这个人是谁”。
---
## 第二段0:32 - 1:05
### “鞋底泥泞 / 重力向下 / 钢铁峡谷 / 何处为家”
### 情绪功能
从自然旷野进入城市边缘。
表现“现实压力”和“系统压迫感”。
### 画面方向
城市边缘、钢铁峡谷、废弃道路、桥下空间、湿冷地面。
可以用高位观察,看一个小人物穿过巨大的城市结构。
### 构图调用
主要调用 **B 高位观察型**
### 关键原则
不要拍成都市宣传片。
城市不是繁华背景,而是压迫性的峡谷。
---
## 第三段1:05 - 1:59
### “别问终点 / 路还很长 / 夜色降临 / 点燃星光 / 那一簇火 / 指引方向”
### 情绪功能
从“外部压力”进入“内部支撑”。
主角还没找到答案,但出现了第一束微弱的方向感。
### 画面方向
黄昏转夜。
风沙、湿路、远方微光、小火、雨后水面。
主角仍然小,不要让他变成英雄剪影。
### 构图调用
A + D 的前奏。
这段可以开始埋入火光,但不要让同行者过早出现。
### 关键原则
火光不是胜利。
火光只是“还能继续”的一点温度。
---
## 第四段1:59 - 3:24
### 主体副歌:
“我走过泥泞,也曾身陷无名旷野……”
“直到在路上,迎着破晓光芒万丈!”
“在这条路上,燃烧寂静的篝火啊!”
### 情绪功能
这是全片情绪展开的主体。
不是炫技,而是把“失败、重启、继续走”的内在重量释放出来。
### 画面方向
泥泞旷野、公路、风化鞋跟、斑驳行囊、夜路、雨水、火光。
主角可以出现更多,但仍以背影、侧影、中远景为主。
### 构图调用
A 为主B 为辅助D 开始增强。
C 的“泥泞里的星空”必须在这一段首次真正成立。
### 关键原则
“光芒万丈”不要拍成商业大片式太阳爆发。
它应该是:泥水里、低处、微弱但真实的星光被看见。
---
## 第五段3:24 - 3:58
### Guitar solo
### 情绪功能
给观众一个无歌词的呼吸段。
这段不是剧情推进,而是内心空间打开。
### 画面方向
更少人物,更多路、天、泥、水、火、风。
可以用慢镜头感、横移感、远景凝视感。
让画面像吉他的延音一样铺开。
### 构图调用
A + C。
这里可以安排第二次“泥泞里的星空”,但比第一次更清楚。
### 关键原则
不要填满。
Solo 段要留白,让观众自己走进画面。
---
## 第六段3:58 - 4:16
### “向前走 / 别回头 / 泥泞里 / 有星空”
### 情绪功能
全片核心揭晓。
这不是一句口号,而是一句被画面证明过的话。
### 画面方向
低机位,贴近泥地。
水洼里不是日出倒影,而是暗夜或黎明前的破碎星空。
旧靴从水洼边经过,脚印留在泥里,星光被水纹打碎。
### 构图调用
**C 泥泞里的星空,重做强化版。**
### C 的修正方向
这类画面后续必须避免:
* 太亮;
* 像日出 / 日落;
* 只有现实泥地,没有诗性;
* 星空倒影太弱;
* 水洼面积太小;
* 靴子喧宾夺主。
正确方向是:
> 夜色更深。
> 泥水更近。
> 星空更碎。
> 人更少。
> 意象更安静。
这应该成为全片的灵魂镜头。
---
## 第七段4:16 - 4:54
### Outro
### 情绪功能
不做胜利结尾。
做“继续在路上”的余韵。
### 画面方向
夜路。
小篝火。
远处第二簇、第三簇火。
主角不必走向他们,也不必会师。
他只是停一下,看见远方还有火,然后继续上路。
### 构图调用
**D 夜路篝火型**。
### 关键原则
结尾不要拥抱,不要团队集合,不要胜利大合照。
远方火光只说明一件事:
> 这条路上,不止我一个人。
---
# 4. 视觉母题
## 主母题:路
路是全片最重要的叙事对象。
它可以是:
* 泥泞路;
* 荒野路;
* 城市边缘废弃路;
* 桥下湿路;
* 夜色公路;
* 水洼中的反光路径。
路不是背景。
路就是命运本身。
---
## 灵魂母题:泥泞里的星空
这是全片的精神核心。
它表达的不是“困境过去了”,而是:
> 人还在泥里。
> 但他终于在泥里看见了星空。
这个意象必须克制。
不能太梦幻,不能太亮,不能太像奇幻电影。
它应该像现实里偶然发生的一瞬间:
雨后的泥水,夜空倒在里面,脚步一动,星光碎开。
---
## 情绪母题:火
火代表方向、温度和同行者。
但火不能变成篝火晚会。
它必须小、远、克制。
火的递进可以是:
1. 前段没有火;
2. 中段出现一簇小火;
3. 副歌后火光变稳定;
4. 结尾远处出现第二簇、第三簇火;
5. 不会师,只确认。
---
## 人物母题:行者
主角不是英雄,不是流浪汉,不是摇滚明星。
他是:
> 一个被系统磨过,但精神没有塌的人。
他可以疲惫,可以狼狈,可以沉默。
但不能破败,不能失去尊严。
---
# 5. 人物设定摘要
## 人物身份
50 岁左右的中年男性行者,以强哥本人为原型,但当前阶段不使用真实脸。
## 气质
沧桑摇滚,温暖疲惫,孤独但坚定。
## 服装
深灰 / 暗卡其 / 煤黑色旅人长外套。
深色内搭。
旧背包。
旧靴子。
头发稍乱,有胡茬。
## 镜头关系
多数时候不看镜头。
以背影、侧影、远景小人物、局部动作、低头行走为主。
## 人物占比
全片大多数镜头控制在画面面积的 **1/8 到 1/5**
近景极少,只在必要情绪点出现。
---
# 6. 场景系统摘要
## 主场景一:清晨泥泞旷野
对应开头。
负责建立“路还很长”。
## 主场景二:城市边缘 / 钢铁峡谷
对应现实压力。
负责表现“何处为家”的压迫感。
## 主场景三:无名旷野 / 风沙路
对应副歌。
负责承载“走过泥泞、身陷旷野”。
## 主场景四:夜路水洼 / 泥泞星空
对应核心意象。
负责承载“泥泞里,有星空”。
## 主场景五:夜色篝火 / 远方火点
对应结尾。
负责承载“还有人在路上”。
---
# 7. 镜头结构建议
整支歌 4 分 54 秒,不建议一行歌词配一个镜头。
更适合做成 **段落式镜头组**
建议总镜头量:
> **36 - 48 个镜头。**
大致分配:
| 段落 | 时间 | 镜头数量建议 | 主要功能 |
| ----------- | ----------: | ------: | ------------- |
| 前奏 | 0:00 - 0:16 | 3 - 4 | 建立世界和路 |
| 第一段 | 0:16 - 0:32 | 4 - 5 | 引出行者 |
| 第二段 | 0:32 - 1:05 | 6 - 7 | 城市压力与现实重力 |
| 第三段 | 1:05 - 1:59 | 7 - 9 | 夜色、火光、继续前行 |
| 主体副歌 | 1:59 - 3:24 | 12 - 16 | 情绪释放,泥泞星空首次成立 |
| Guitar solo | 3:24 - 3:58 | 5 - 6 | 留白、延音、内心空间 |
| 最后四句 | 3:58 - 4:16 | 3 - 4 | 灵魂意象揭晓 |
| Outro | 4:16 - 4:54 | 5 - 7 | 远方火光,继续上路 |
---
# 8. 全片画面递进
## 第一阶段:世界先于人出现
观众先看见路,再看见人。
主角是被世界包围的行者。
## 第二阶段:城市和泥泞压下来
画面从旷野进入城市边缘。
钢铁、湿路、重力、风沙,把人压得更小。
## 第三阶段:夜色里出现第一簇火
不是答案,而是微弱方向。
主角仍然孤独,但不再完全失重。
## 第四阶段:泥泞里第一次看见星空
这不是奇观。
这是全片最重要的内心转折:
困境没有消失,但意义开始出现。
## 第五阶段:远方出现同行者火光
结尾不解决一切。
只完成一次确认:
> 我还在路上。
> 远处也有人在路上。
---
# 9. 风险点
## 风险一:人物写真感回潮
只要人物太大、太居中、太正脸,就会偏离方向。
后续镜头清单必须持续压住人物占比。
## 风险二:泥泞星空不够诗性
这是当前唯一需要重点补强的方向。
C 不能只是现实泥地,也不能只是漂亮倒影。
它必须同时有“低处的狼狈”和“高处的宇宙”。
## 风险三:篝火变露营广告
D 已经成立,但后续必须控制人数、火势、氛围。
不能热闹,不能团建,不能胜利会师。
## 风险四:城市段变科技片
虽然背景来自 AI 转型和自动化失败,但 MV 不应出现代码、屏幕、UI、流程图。
城市段只表现系统压迫,不解释技术过程。
## 风险五:副歌变鸡血大片
“光芒万丈”不能拍成商业英雄片。
真正的力量感来自克制,而不是特效爆发。
---
# 10. 阶段3结论
这支 MV 的总纲可以确定为:
> **一个 50 岁的行者,在清晨、城市、泥泞、风沙和长夜中持续前行。
> 他没有赢得胜利,也没有抵达终点。
> 但他在泥泞倒影里看见星空,在远处黑暗里看见火光。
> 于是他知道:自己还在路上,远方也有人在路上。**
下一步建议进入:
> **阶段4通用表达与视觉系统设计**
重点不是再扩剧情,而是把人物系统、场景系统、色彩系统、镜头语言、构图比例、泥泞星空修正规则、篝火出现规则全部定下来。

View File

@ -0,0 +1,690 @@
# 《在路上》关键单镜骨架展开 V1
本次展开 3 个镜头:
1. **S-46泥泞里有星空**
2. **S-10钢铁峡谷**
3. **S-51结尾大远景**
---
# 镜头 S-46泥泞里有星空
## 1. 对应歌词 / 音乐段落
对应最后四句中的核心句:
> 泥泞里
> 有星空
时间位置约:
> **3:58 - 4:16**
这是全片的灵魂镜头。
---
## 2. 本镜情绪功能
这个镜头不是装饰性意象,而是整支 MV 的核心揭晓。
它要让观众明白:
> 主角没有离开泥泞。
> 泥泞还在。
> 但他终于在泥泞里,看见了星空。
所以这不是“困境结束”的画面。
这是“困境中出现意义”的画面。
---
## 3. 核心画面
低机位,贴近地面。
画面主体是:
* 一片真实的泥泞水洼;
* 水面有轻微波纹;
* 泥边有旧靴痕迹;
* 画面边缘出现旧靴或外套下摆的一小部分;
* 水洼倒影里出现破碎的星空;
* 星光不是完整银河,而是被泥水、水纹、脚印打碎的星点。
人物本体不要出现完整脸。
最多只出现:
* 旧靴边缘;
* 模糊影子;
* 经过水洼的下半身暗影。
画面重点必须是:
> **泥水里的星空倒影。**
---
## 4. 人物与镜头关系
人物在这一镜里不是主体。
人物只是让观众知道:
> 这个星空不是抽象意象,而是行者在路上看见的。
### 人物可见度
建议:
* 局部;
* 靴子边缘;
* 暗影;
* 不露脸;
* 不拍成鞋靴广告。
### 人物占比
人物相关元素不超过画面 15%。
真正的主体应该是水洼、泥地和倒影。
---
## 5. 场景与视觉母题
调用阶段4里的核心母题
* 泥泞;
* 水洼;
* 旧靴;
* 夜色;
* 破碎星空;
* 低处见高处。
这是 **C泥泞里的星空修正版**
---
## 6. 构图方向
### 推荐构图
* 16:9 横屏;
* 低机位;
* 水洼占画面中心或偏下方;
* 泥地纹理占据前景;
* 星光倒影在水面中出现;
* 旧靴或人物暗影位于画面边缘;
* 不要把星空放在真实天空里成为主画面。
### 关键判断
这一镜不是“抬头看星空”。
而是:
> **低头看泥水,发现星空也在里面。**
---
## 7. 光线与色彩
### 光线
* 夜色或黎明前;
* 整体偏暗;
* 水面有微弱反光;
* 星光冷而碎;
* 不出现明显太阳;
* 不要夕阳 / 朝阳暖光。
### 色彩
* 暗蓝灰;
* 泥土褐;
* 黑灰;
* 少量冷白星点;
* 暖色极少,最好没有明显火光干扰。
---
## 8. 与前后镜头关系
### 前一镜 S-45别回头
主角经过旧脚印,不回头。
### 本镜 S-46泥泞里有星空
镜头从行动落到意象。
观众终于看见全片最重要的答案。
### 后一镜 S-47Outro 起
从泥水星空过渡到夜路小火。
星光变成火光。
内心确认转向远方同行者确认。
---
## 9. 执行层提示词要点
后续 Codex / 图像执行层正式写 Prompt 时,必须包含这些要点:
* 16:9 horizontal cinematic frame
* close-to-ground composition
* muddy puddle as main subject
* broken starry sky reflected in dark water
* realistic wet mud texture
* old worn boot only at the edge of the frame
* night or pre-dawn darkness
* poetic documentary realism
* no portrait emphasis
* subtle, restrained, not fantasy.
注意:这些只是**执行要点**,不是正式最终 Prompt。
---
## 10. 验收关注点
强哥审这一镜时,只看 6 件事:
1. **星空倒影够不够明确?**
2. **泥水现实质感够不够?**
3. **有没有太亮、太像日出 / 日落?**
4. **有没有过度魔幻?**
5. **靴子有没有抢戏,变成鞋靴广告?**
6. **是否真的传达出“泥泞里,有星空”?**
如果这镜成立,整支 MV 就有灵魂。
---
# 镜头 S-10钢铁峡谷
## 1. 对应歌词 / 音乐段落
对应歌词:
> 钢铁峡谷
> 何处为家
时间位置约:
> **0:32 - 1:05**
---
## 2. 本镜情绪功能
这个镜头承担的是“现实压迫感”。
它不是在拍城市。
它是在拍:
> 一个中年行者,被巨大的现代系统压到很小。
这里的“钢铁峡谷”不是具体科技,不是 AI 界面,不是代码屏幕。
它是现实生活、工作系统、自动化失败、城市结构和内心重力的视觉转译。
---
## 3. 核心画面
城市边缘或高架桥下。
画面中有:
* 巨大的桥梁结构;
* 冷硬混凝土;
* 钢铁梁柱;
* 湿冷地面;
* 远处城市墙面或建筑缝隙;
* 主角很小,从结构底部穿过。
人物应该像被夹在巨大结构之间。
画面要有“峡谷感”:
* 上方压下来;
* 两侧夹住;
* 前方很长;
* 人在底部。
---
## 4. 人物与镜头关系
人物不是城市大片里的时尚男主。
人物应该是:
* 很小;
* 背影或侧影;
* 沉默穿行;
* 不看镜头;
* 不停下来摆拍。
### 人物占比
建议控制在:
> 画面 1/10 - 1/6
城市结构必须大于人物。
---
## 5. 场景与视觉母题
调用阶段4里的
* 城市边缘;
* 钢铁峡谷;
* 系统压迫;
* 高位观察;
* 湿冷地面;
* 小人物。
这是 **B高位观察型 / 城市边缘纪录片感** 的核心镜头之一。
---
## 6. 构图方向
### 推荐构图 1高位观察
从高处俯看人物穿过高架桥下或城市夹缝。
地面、墙体、道路、水洼形成几何结构。
人物很小,像系统边缘的一个移动点。
### 推荐构图 2远景平视
镜头在远处低一点的位置,看巨大桥梁 / 建筑形成压迫性通道。
主角在画面底部或偏侧穿行。
### 不推荐
* 城市夜景宣传片;
* 精致 CBD
* 霓虹赛博;
* 玻璃幕墙大片;
* 主角站中间摆拍。
---
## 7. 光线与色彩
### 光线
* 阴天;
* 桥下阴影;
* 湿冷反光;
* 不明亮;
* 不戏剧化打光。
### 色彩
* 钢铁灰;
* 混凝土灰;
* 湿地蓝灰;
* 少量锈色;
* 人物服装低饱和深色。
不要赛博蓝紫。
不要科技感荧光。
不要商业城市大片橙蓝。
---
## 8. 与前后镜头关系
### 前一镜 S-09重力向下
主角在巨大桥梁阴影下穿行,现实压力开始压下来。
### 本镜 S-10钢铁峡谷
压迫感被放大到段落核心。
城市变成峡谷,人物变成底部小坐标。
### 后一镜 S-11何处为家
主角从城市边缘走过,不进入室内。
继续强化“在门外”的无归属感。
---
## 9. 执行层提示词要点
后续 Codex / 图像执行层正式写 Prompt 时,必须包含这些要点:
* 16:9 horizontal cinematic frame
* high-angle or distant observational shot
* urban edge under massive overpass or steel-concrete canyon
* tiny middle-aged traveler walking through the bottom of the frame
* wet ground, puddles, cold gray light
* documentary realism
* oppressive scale relationship
* no futuristic UI, no code, no sci-fi city.
这些仍然是**策划要点**,不是最终生图 Prompt。
---
## 10. 验收关注点
强哥审这一镜时看 7 件事:
1. **城市有没有压迫感?**
2. **人物是否足够小?**
3. **有没有“峡谷”感?**
4. **画面是不是城市边缘,而不是繁华城市宣传片?**
5. **有没有避免科技 UI、代码、AI 工具感?**
6. **人物有没有摆拍感?**
7. **这一镜能不能承接“重力向下 / 何处为家”?**
这镜成立,城市段就不会变成普通素材。
---
# 镜头 S-51结尾大远景
## 1. 对应歌词 / 音乐段落
对应:
> Outro
> Acoustic guitar slowly fading out
时间位置约:
> **4:16 - 4:54 末尾**
这是全片最后余韵镜头。
---
## 2. 本镜情绪功能
这个镜头不是总结胜利。
不是会师。
不是拥抱。
不是团队集合。
它的情绪功能只有一个:
> 确认远方有人,然后继续在路上。
这个结尾必须让观众感觉:
* 主角没有抵达终点;
* 远方也不是终点;
* 但他不再是完全孤独的;
* 这条路上,确实还有别人。
---
## 3. 核心画面
大远景。
夜色中的旷野或长路。
画面里有:
* 一条暗色泥路或荒野道路;
* 主角很小,继续往前走;
* 近处或身后有一簇小火;
* 远处黑暗里有第二簇、第三簇微弱火光;
* 天空深暗,有少量星点或冷光;
* 世界仍然很大。
主角不奔跑,不挥手,不回头大笑,不走向人群。
他只是知道远方有火,然后继续走。
---
## 4. 人物与镜头关系
人物在这一镜里应该非常小。
### 人物可见度
* 极小背影;
* 大远景;
* 不露脸;
* 不强调表情;
* 只看得出背包、外套和行走方向。
### 人物占比
建议:
> 1/20 - 1/12
比前面常规镜头更小。
因为结尾要回到最初的原则:
> 世界比人更大,路比人更长。
---
## 5. 场景与视觉母题
调用阶段4里的
* 夜路;
* 小篝火;
* 远方火点;
* 星空;
* 旷野;
* 行者;
* 继续。
这是 **D夜路篝火型 / 远处同行者火光** 的最终收束镜头。
---
## 6. 构图方向
### 推荐构图
* 16:9 横屏;
* 大远景;
* 路从近处延伸到远处;
* 主角在画面下方或偏侧;
* 近处小火不要太大;
* 远方火点分散在黑暗里;
* 天空和地面都要有足够留白;
* 不要把人物、火堆、人群放中间做成会师画面。
### 画面重心
不是人物。
不是火。
而是:
> 夜色里的路,以及路上那些微弱但真实的火。
---
## 7. 光线与色彩
### 光线
* 深夜蓝黑;
* 小篝火暖橙;
* 远处火点更弱;
* 天空少量冷星光;
* 暗部要保留层次。
### 色彩
* 深蓝黑;
* 暗土褐;
* 冷灰;
* 少量暖橙火光。
暖色不能铺满画面。
暖色只是提醒观众:
> 那里有人。
---
## 8. 与前后镜头关系
### 前一镜 S-50再次上路
主角背起包,离开自己的小火,继续往远方走。
### 本镜 S-51最后余韵
镜头拉远或直接切到大远景。
主角成为世界里的一个小点。
远处多簇火光微弱存在。
### 结尾情绪
音乐逐渐淡出。
画面不需要给答案。
只留下:
> 他还在路上。
> 远方也有人在路上。
---
## 9. 执行层提示词要点
后续 Codex / 图像执行层正式写 Prompt 时,必须包含这些要点:
* 16:9 horizontal cinematic wide shot
* vast dark wilderness road at night
* tiny middle-aged traveler walking away
* small campfire nearby, one or two distant firelights far away
* not a camping scene, not a gathering
* poetic documentary road film
* restrained warm firelight against deep blue-black night
* landscape narrative, human as small anchor.
这些是执行层写正式 Prompt 的素材要点,不是最终 Prompt。
---
## 10. 验收关注点
强哥审这一镜时看 7 件事:
1. **远方火光是否像“还有人在路上”?**
2. **有没有变成露营广告?**
3. **有没有变成团队会师?**
4. **人物是否足够小?**
5. **路是否仍然比人更重要?**
6. **画面是否温暖但克制?**
7. **结尾有没有保留未完成感?**
这镜成立,整支 MV 的结尾就不会俗。
---
# 三镜之间的关系
这三个镜头分别承担全片三根柱子:
| 镜头 | 功能 | 代表什么 |
| ---------- | ---- | ------- |
| S-10 钢铁峡谷 | 现实压力 | 世界把人压小 |
| S-46 泥泞星空 | 精神核心 | 泥里也能看见星 |
| S-51 结尾大远景 | 情绪收束 | 远方也有人在走 |
它们连起来,就是这支 MV 的真正主线:
> 人被世界压小。
> 人在泥里看见星。
> 人在远方看见火。
> 所以人继续走。
# 回答两个问题
## 1. 其他单镜是否也需要展开?
**不需要全部展开到同等深度。**
正确做法应该分级:
| 镜头等级 | 是否需要展开 | 说明 |
| ------- | ------ | ----------------- |
| A 级关键镜头 | 必须展开 | 决定全片气质、灵魂意象、结尾情绪 |
| B 级功能镜头 | 选择性展开 | 比如城市压迫、人物局部、火光铺垫 |
| C 级过渡镜头 | 不必单独展开 | 可由镜头清单直接进入执行层批量处理 |
这支 MV 最应该优先展开的就是:
1. **S-46 泥泞里,有星空**:灵魂镜头;
2. **S-10 钢铁峡谷**:现实压迫镜头;
3. **S-51 结尾大远景**:全片余韵镜头。
其他镜头后面可以按“镜头组”展开,比如:
* 清晨长路组;
* 城市边缘组;
* 旧靴 / 背包 / 手部局部组;
* 夜路篝火组;
* 水洼倒影组。
不用一开始把 51 个镜头都展开到单镜级别。那样会太重,也容易在还没进入执行前过度消耗。
---
## 2. 单镜展开是谁的工作Codex 必须做吗?
要分两层。
### 第一层:策划层单镜展开
这是我现在做的工作。
我负责说明:
* 这个镜头在全片里的情绪功能;
* 对应歌词 / 音乐段落;
* 画面核心信息;
* 人物与镜头关系;
* 场景与视觉母题;
* 构图控制;
* 风格调用;
* 审图关注点;
* 执行层应该注意什么。
但我不输出正式生图 Prompt、不输出 Codex JSON、不输出执行包。
---
### 第二层:执行层镜头生产
这部分应该由 **Codex / 图像执行层 / Prompt Advisor** 来做。
如果后面要正式批量生成 MV 资产,那 Codex 基本是需要的。
因为它要处理:
* 每个镜头的正式生图 Prompt
* 人物参考图调用;
* 风格锚点调用;
* 画幅、编号、文件命名;
* 批量出图;
* 结果筛选;
* 失败重跑;
* 同一镜头多版本比较;
* 素材落盘;
* 后续视频剪辑资产管理。
所以你的判断是对的:
> **正式生产时Codex / 执行层必须接手,而且每个镜头都需要正式提示词。**
但那不是我现在这一层输出。
我现在先把关键镜头展开成“导演策划说明”,后面执行层再把它们翻译成正式 Prompt。
---

View File

@ -0,0 +1,51 @@
# 先说明:为什么要做“文案标注稿”?
强哥,**标注稿不是必须为了好看,而是为了把锚点板变成“标准件”。**
人物锚点板如果只有图,它的价值是:
> 看起来像这个人。
但一旦加上少量标注,它的价值就变成:
> 后续任何人、任何工具、任何镜头都知道:哪些东西必须保持一致,哪些东西不能乱变。
比如同一张人物图,执行层可能会理解成:
* 重点是脸;
* 重点是外套;
* 重点是背包;
* 重点是中年气质;
* 重点是摇滚感;
* 重点是旅人感。
如果不标注,大家会各抓各的重点。
但《在路上》这支 MV 的人物一致性,恰恰不是靠脸,而是靠:
> **发型轮廓 + 长外套 + 旧背包 + 旧靴 + 步态 + 疲惫但不破败的气质。**
所以标注稿的意义是:
1. **把审美变成规则**
不只是“我觉得像”,而是知道为什么像。
2. **把人物图变成执行参考**
后续做背影、侧影、远景小人物时,仍然知道该抓什么。
3. **防止跑偏**
防止变成流浪汉、男模、旅行博主、英雄海报主角。
4. **方便你自己审图**
看到一张新图时,可以逐项对照:外套对不对,包对不对,背影对不对,气质有没有塌。
但有一点要注意:
> **标注不一定非要压在图上。**
可以有两种做法:
* **展示版锚点板**:图面干净,只有少量短标签;
* **工作版锚点板**:旁边有详细标注,用于执行和审查。
所以文案标注稿不是为了把页面做复杂,
而是为了让这张板从“参考图”升级成“角色标准”。

View File

@ -0,0 +1,485 @@
# 《在路上》人物锚点板策划说明 V1
## 先回答你的问题
**是的,人物锚点板应优先使用纯净背景。**
而且我建议不是二选一,而是:
> **主锚点板用浅色纯底(优先白色 / 浅灰白)**
> **同时补一套透明背景人物切片**
这样最好。
---
## 为什么这么做
因为你这张“人物锚点板”的任务,不是做氛围图,也不是做 MV 成片画面。
它的任务是:
1. **锁定人物一致性**
2. **锁定服装和道具一致性**
3. **锁定正 / 侧 / 背 / 行走轮廓**
4. **让后续远景、背影、侧影镜头都还能认出是同一个人**
5. **给后续执行层当作统一参考基座**
所以它最怕的不是“单调”,而是:
* 背景干扰人物轮廓;
* 场景影响服装颜色判断;
* 光影太戏剧化,导致发型、胡茬、外套长度不好判断;
* 不同角度像不同人;
* 外套、背包、靴子细节看不清。
---
# 一、背景选择结论
## 方案结论:建议做“两套”
### A 套:主锚点板
**背景用纯净浅色底**
优先建议:
* **白色**
* **浅灰白**
* **非常浅的暖灰**
这套的作用是:
* 方便看清人物轮廓;
* 方便审服装、发型、包、靴;
* 方便比较正侧背是否一致;
* 方便后续当“角色设定板”使用。
---
### B 套:补充执行资产
**透明背景人物单体切片**
这套的作用是:
* 方便后续拼接参考;
* 方便做局部调用;
* 方便执行层做进一步图像参考;
* 方便作为人物素材与风格板组合。
---
## 不建议只用透明背景
透明背景当然有用,
但**如果整张锚点板全是透明背景,不一定最适合策划审查。**
原因很简单:
1. 透明背景在很多界面里会显示成棋盘格,反而干扰审图;
2. 不利于一眼看整体版式;
3. 不利于直接做“设定板”阅读;
4. 后续标注文字、箭头、服装说明时,也不如纯底稳定。
### 所以更优解是:
> **主板纯底 + 单体透明切片**
---
# 二、推荐的背景策略
## 最优选择
### **浅灰白纯底,比纯白更稳**
为什么不是死白?
因为主角服装是:
* 深灰
* 暗卡其
* 煤黑外套
* 深色内搭
* 旧背包
* 旧靴子
如果背景是完全纯白,也能用;
但如果边缘处理一般,深色人物边缘可能显得有点硬。
所以更建议:
> **背景用非常浅的中性灰白 / 暖灰白**
这样有几个好处:
* 人物轮廓更清楚;
* 深色外套边缘更容易看;
* 比纯白更柔和;
* 看起来仍然是“无干扰背景”。
---
## 不建议的背景
不建议用:
* 风景背景
* 城市场景背景
* 泥地背景
* 阴影太重的摄影棚背景
* 渐变很强的艺术背景
* 有地面透视的“摆拍背景”
原因:
这会让锚点板从“设定板”变成“宣传图”,失去功能性。
---
# 三、人物锚点板的正确定位
这张图建议你把它理解成:
> **角色设定总板 / Character Anchor Board**
它不是单纯“正脸定妆照”,
而是一个后续所有镜头都要回看的“人物系统说明书”。
---
# 四、推荐版式结构
我建议这张锚点板做成 **一个主板 + 一组补充小图**
---
## 主板结构建议
# 《在路上》人物锚点板
### 版面结构:建议 3 区
---
## 区块 A三视图主区最重要
这是整张板子的核心。
### 应包含:
1. **正面全身**
2. **侧面全身**
3. **背面全身**
### 作用:
* 锁定人物整体轮廓
* 锁定外套长度
* 锁定背包体量
* 锁定靴子高度和旧感
* 锁定头发长度和后脑勺轮廓
* 锁定背影可识别度
### 版式建议:
三个人物高度一致,居中排开。
中间正面,左侧或右侧放侧面,另一侧放背面。
---
## 区块 B状态图区辅助识别
### 建议包含:
4. **半身状态图**
5. **行走侧身**
6. **行走背影**
### 作用:
* 半身图:确认脸部气质、胡茬、眼神、年龄感
* 行走侧身:确认步态和外套动态
* 行走背影:确认“远景时仍像这个人”
### 重点提醒:
这里仍然要克制。
即使是半身状态图,也不要拍成精致写真。
---
## 区块 C服装 / 道具拆解区
### 建议包含:
7. **长外套拆解**
8. **内搭说明**
9. **旧背包说明**
10. **旧靴说明**
### 作用:
* 让后续任何镜头都知道“什么东西必须稳定”
* 避免后面出图时外套长度乱变、包型乱变、鞋型乱变
### 服装说明重点不是品牌,而是特征:
* 长外套:长度、颜色、材质感、旧感、下摆状态
* 背包:旧但不是破,结构偏实用,不像潮流机能包
* 靴子:旧、沾泥、耐走,不像时尚短靴
* 内搭:深色、克制,不抢戏
---
# 五、推荐附加说明文字
这张板最好不要只有图,
建议配少量功能性文字标签。
但文字一定要短,不能写成长段说明。
---
## 建议标注的项目
### 1. 人物基本标签
* 年龄50 岁左右
* 气质:沧桑摇滚 / 温暖疲惫 / 孤独但坚定
* 状态:可以狼狈,不能破败
* 身份:路上行者
### 2. 外形关键词
* 深色微乱发
* 明显胡茬
* 深灰 / 暗卡其长外套
* 深色内搭
* 旧背包
* 旧靴子
### 3. 边界说明
可以有:
* 风尘感
* 疲惫感
* 使用痕迹
不能有:
* 流浪汉感
* 男模时尚大片感
* 摆拍英雄感
* 过度精致造型感
---
# 六、这张板最应该审什么
这张板不是看“帅不帅”,
而是看下面 6 件事。
---
## 1. 正侧背是不是同一个人
这是最核心的。
要检查:
* 头型是否稳定
* 发型是否稳定
* 身材比例是否稳定
* 肩线是否稳定
* 外套是否稳定
* 背包是否稳定
---
## 2. 背影是否成立
因为你这支 MV 大量镜头会是背影和远景。
所以一个关键判断是:
> 不看脸,只看背影和轮廓,能不能认出还是这个人?
如果不能,这张锚点板就不够好。
---
## 3. 行走状态是否成立
这个人物不是站在影棚里拍证件照,
他是一个“在路上”的人。
所以必须看:
* 走起来是否自然;
* 外套在行走状态下是否成立;
* 背包在走路时是否合理;
* 整体有没有“继续向前”的感受。
---
## 4. 疲惫感和尊严感是否平衡
你的边界非常重要:
> 人物可以疲惫,但不能破败。
> 可以狼狈,但不能失去尊严。
所以要特别审:
* 有没有被做成流浪汉;
* 有没有太脏太惨;
* 有没有塌掉;
* 有没有变成“失败者形象消费”。
---
## 5. 服装是否足够稳定、足够克制
服装不是时尚主角,
它是人物识别系统的一部分。
要看:
* 颜色是否低饱和;
* 是否能融入旷野、城市边缘、泥地和夜色;
* 是否既有使用痕迹,又不至于破败;
* 是否有“旅人感”,而不是“潮男感”。
---
## 6. 是否适合远景缩小后仍保留识别性
因为后面人物经常只占画面 1/8 - 1/5。
所以这张板的终极问题是:
> 缩小之后,还认得出来是这个行者吗?
最关键的识别来源通常不是脸,
而是:
* 长外套轮廓
* 背包轮廓
* 靴子轮廓
* 肩背姿态
* 步态倾向
* 头发与头肩线条
---
# 七、我建议你的人物锚点板最终包含这些格子
## 推荐版式9 格最稳)
### 第一排:三视图
1. 正面全身
2. 侧面全身
3. 背面全身
### 第二排:状态图
4. 半身状态
5. 行走侧身
6. 行走背影
### 第三排:拆解图
7. 外套 / 内搭说明
8. 背包说明
9. 靴子说明
---
# 八、如果只能先做一版,优先级怎么排
如果你想先快速做 MVP 版,我建议优先级如下:
## 第一优先级(必须有)
1. 正面全身
2. 侧面全身
3. 背面全身
4. 半身状态图
## 第二优先级(强烈建议有)
5. 行走侧身
6. 行走背影
## 第三优先级(完善时补)
7. 服装拆解
8. 背包拆解
9. 靴子拆解
---
# 九、最实用的执行建议
## 最佳组合输出
### 输出 1主锚点板
* 浅灰白纯底
* 9 格或 6 格版式
* 适合审查、讨论、定人物系统
### 输出 2透明背景人物切片
至少导出这些:
* 正面全身
* 侧面全身
* 背面全身
* 行走侧身
* 行走背影
### 输出 3简版文字说明
单独一页或同页角落放:
* 年龄
* 气质
* 发型
* 服装关键词
* 道具关键词
* 禁止跑偏方向
---
# 十、我的结论
## 关于背景
**是,人物锚点板用纯净背景更好。**
更准确说:
> **主锚点板:浅灰白纯底最佳**
> **补充资产:透明背景切片最佳**
这比“只用白底”或“只用透明底”都更完整。
---
## 关于这张板的价值
这张板不是为了好看,
而是为了后面所有镜头都能持续回答一个问题:
> 这个人,还是不是《在路上》的那个行者?
---
如果你愿意,下一步我可以继续给你输出:
## 《在路上》人物锚点板页面结构稿
我会直接按“这张板怎么排版、每个格子写什么、每个格子承担什么判断任务”的方式,给你一版更像可执行文档的结构稿。

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