wantsong
/
video-workbench
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
video-workbench/handoff/2026-06-24-character-consis...

8.1 KiB
Raw Blame History

R5 Brief-Ownership Formal-Run Handoff

Date: 2026-06-24

Project:

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:

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:

S-07
S-08
S-09

Expected new versions if no new files appear before R5:

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:

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:

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

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:
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:

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.