diff --git a/README.md b/README.md
index cf3fb3f..a7719f1 100644
--- a/README.md
+++ b/README.md
@@ -34,6 +34,8 @@ projects/
       s02/
 
 handoff/
+docs/
+  cases/
 investigations/
 garden-gpt-image-2/
 requirements/
@@ -47,6 +49,7 @@ ccpe-consumption/
 - `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>/slides/` is the working area for slide, page, or shot execution. Each `sNN/` folder keeps that unit's prompts, narration, generated images, audio, and local notes together. Files inside `sNN/` must carry the `sNN` prefix, and iteration files use `sNN-vN-type.ext`, such as `s03-v1-prompt.md`.
 - `handoff/` is for repo-level, cross-project, or context-window handoff notes.
+- `docs/cases/` is the Codex-side local case-pattern library extracted from old real GPT cases. It preserves execution patterns, not old prompts, JSON packages, paths, or global text-rendering rules.
 - `investigations/` is for research reports, experiments, comparisons, and draft workflow proposals. It replaces `tmp/` for durable investigation evidence.
 - `garden-gpt-image-2/` is reserved for local image-generation prompt/workflow traces when that tool path is used.
 
diff --git a/VIDEO_WORKBENCH.md b/VIDEO_WORKBENCH.md
index 8473be9..7ee7141 100644
--- a/VIDEO_WORKBENCH.md
+++ b/VIDEO_WORKBENCH.md
@@ -40,6 +40,8 @@ projects/
 
 Use root-level `handoff/` for repository-level, cross-project, series-level, or context-window handoff notes.
 
+Use `docs/cases/` for Codex-side local case patterns extracted from old real GPT cases. These documents preserve reusable structure, granularity, asset layering, speaker-note style, and review dimensions. They do not restore old GPT final prompts, Codex JSON execution packages, output paths, or global text-rendering rules.
+
 Do not split projects into `active`, `completed`, `abandoned`, `series`, or `standalone` folders. Status and series membership belong in project files because both can change during real production.
 
 If a series needs more structure, create `projects/_series/` when the first real series needs it.
diff --git a/docs/cases/README.md b/docs/cases/README.md
new file mode 100644
index 0000000..3666362
--- /dev/null
+++ b/docs/cases/README.md
@@ -0,0 +1,65 @@
+# Video Workbench Case Pattern Library
+
+This directory is the local case-pattern library for Codex execution work in Video Workbench.
+
+It is extracted from old GPT case files only at the level of structure, granularity, page or storyboard method, speaker-note style, visual asset layering, and review dimensions. It is not a prompt library and not a copy of the old GPT knowledge base.
+
+## Source Basis
+
+The first two patterns were localized from:
+
+- `knowledge-vault/prompts/GPT/强哥的策划导演/30_CASE_典型视频分镜案例.md`
+- `knowledge-vault/prompts/GPT/强哥的策划导演/31_CASE_典型培训AI_PPT案例.md`
+
+Those source files remain historical GPT assets in Knowledge Vault. Video Workbench uses the extracted patterns below as Codex-side local execution guidance.
+
+## Cases
+
+| case | use when | local output focus |
+| --- | --- | --- |
+| [science-video-page-style-case.md](science-video-page-style-case.md) | Turning a deep article, model point, or public-facing concern into a PPT-style science video | Shot/page granularity, narration pacing, visual metaphor, review criteria |
+| [training-ai-ppt-case.md](training-ai-ppt-case.md) | Turning AI education, method training, product enablement, or workshop content into a teachable slide deck | Teaching unit design, speaker notes, interaction, editable slide structure |
+
+## Local Use
+
+Use these cases after GPT V2 stage 0-5 planning has been accepted into a project `intake/` directory. Codex then converts the accepted planning into:
+
+- `project.md` for project map and current focus;
+- `execution-plan.md` for execution strategy, batch, round, and next decision;
+- `visual-system/visual-system.md` for visual-system materialization and review;
+- `slides/slides.md` and `slides/sNN/` for page or shot execution facts and assets.
+
+## What To Extract
+
+Extract these parts from old or future real cases:
+
+- medium branch and audience;
+- logic-to-page or logic-to-shot decomposition;
+- page or shot function;
+- one-unit-one-purpose granularity;
+- editable page text vs visual asset vs narration or speaker notes;
+- visual-system anchors and reusable motifs;
+- review dimensions and acceptance criteria;
+- batch/iteration advice.
+
+## What Not To Inherit
+
+Do not inherit these legacy assumptions:
+
+- GPT outputs final image prompts.
+- GPT outputs Codex JSON execution packages.
+- GPT specifies local output paths, task lists, or generation parameters.
+- the old assumption that every image prompt must forbid readable text.
+- old source filenames or schemas become current Video Workbench contracts.
+
+For current Video Workbench, text placement is an execution decision. Body copy is usually rendered in the editable PPT or video page layer; image-generated labels, formulas, diagrams, or text are allowed only when the execution plan and review criteria explicitly require that layer.
+
+## Review Dimensions
+
+When adding a new case pattern, check:
+
+- Does the pattern state which medium branch it serves?
+- Does it describe unit granularity without copying a full old case?
+- Does it separate source logic, page or shot copy, visual assets, and narration/speaker notes?
+- Does it provide review criteria that Codex can apply during small-batch iteration?
+- Does it avoid old Prompt, JSON, path, and global text-rendering rules?
diff --git a/docs/cases/science-video-page-style-case.md b/docs/cases/science-video-page-style-case.md
new file mode 100644
index 0000000..4f378d5
--- /dev/null
+++ b/docs/cases/science-video-page-style-case.md
@@ -0,0 +1,156 @@
+# Science Video Page-Style Case Pattern
+
+This pattern is for PPT-style science videos: a deep article or model is reduced into a short public-facing video made of page-like shots, narration, and visual assets.
+
+It is extracted from the old `30_CASE` video storyboard case. The original topic, prompts, Codex JSON, output paths, and global text prohibitions are not carried forward.
+
+## Use When
+
+Use this pattern when the target is:
+
+- a 3-10 minute public-facing science, cognition, AI, product-thinking, or method-explainer video;
+- a PPT-style video with page/shot images plus narration;
+- a video that explains a mechanism, risk, contradiction, method, or model through metaphors and staged visual pages;
+- not a drama short, not a full video-editing workflow, and not a character-continuity MV.
+
+## Core Pattern
+
+```text
+source point
+-> public-facing concern
+-> controlling metaphor
+-> video outline
+-> shot/page list
+-> shot/page deep spec
+-> narration
+-> visual asset brief
+-> review and iteration
+```
+
+The case value is not the original topic. The reusable method is "page-style explanation": each shot behaves like a compact visual argument, not like a literal filmed scene.
+
+## Granularity
+
+Default unit size:
+
+- 6-10 units for a short explainer;
+- 25-70 seconds per unit;
+- about 90-260 Chinese characters per unit;
+- one unit carries one logic function;
+- one high-density method unit may be longer, but it still needs one clear governing frame.
+
+Common unit functions:
+
+| function | purpose |
+| --- | --- |
+| hook | create urgency or recognisable public concern |
+| story anchor | give the viewer a concrete person, situation, or conflict |
+| controlling metaphor | make the whole mechanism memorable |
+| mechanism reveal | explain the hidden process or failure mode |
+| practical frame | turn the concept into methods, checks, or choices |
+| closing elevation | return to the larger judgment or changed mental model |
+
+## Local Unit Spec
+
+For Video Workbench, put this in `slides/sNN/sNN-unit-spec.md` or use it as the basis for that file:
+
+| field | purpose |
+| --- | --- |
+| `unit_id` | `sNN` identifier used by local files |
+| `source_anchor` | source paragraph, GPT V2 stage-5 row, or accepted intake note |
+| `narrative_function` | hook, story anchor, metaphor, mechanism, method, or closing |
+| `core_message` | one sentence the viewer should retain |
+| `page_copy` | short overlay text or subtitle-layer copy, if needed |
+| `voiceover_intent` | what narration must explain beyond page copy |
+| `visual_task` | what the visual asset must make visible |
+| `asset_layers` | background, metaphor object, human element, diagram, overlay, audio |
+| `continuity_link` | how this unit connects to the previous and next unit |
+| `review_focus` | the two or three things to inspect first in iteration |
+
+This is a local execution spec, not a final image prompt. Final prompt files remain Codex-owned `sNN-vN-prompt.md` artifacts when image generation is actually performed.
+
+## Page And Asset Layering
+
+Separate layers before prompting or generating images:
+
+| layer | owns |
+| --- | --- |
+| source logic | the concept, contradiction, risk, or method from accepted input |
+| page text | the few words that may be rendered by PPT/video page layer |
+| visual asset | metaphor scene, background, figures, diagram base, mood, composition |
+| narration | full explanation, transition, examples, and punchline |
+| review notes | whether the visual asset really carries the logic |
+
+Do not treat "image contains no readable text" as a global rule. Decide per unit:
+
+- If text must be editable or frequently revised, keep it in the PPT/video page layer.
+- If labels, formulas, UI snippets, or diagram words are essential to the visual explanation, allow them only with explicit review criteria.
+- If the image model is likely to garble precise wording, keep precise wording outside the generated image.
+
+## Shot/Page Design Method
+
+For each unit, answer in this order:
+
+1. What is the viewer supposed to understand or feel at this moment?
+2. What is the simplest visible metaphor or situation that makes it concrete?
+3. What page text is useful, if any?
+4. What must narration explain that the image should not carry alone?
+5. Which part of the unit is high risk: logic, metaphor, composition, text placement, or visual generation?
+6. What would make the unit fail review?
+
+The visual should not decorate the narration. It should do at least one of these jobs:
+
+- compress an abstract mechanism;
+- expose a contradiction;
+- make a risk feel real;
+- separate similar concepts;
+- hold attention while narration explains a dense idea;
+- signal a transition in the argument.
+
+## Review Dimensions
+
+Review generated or drafted units against these dimensions:
+
+| dimension | pass condition |
+| --- | --- |
+| logic clarity | one unit maps to one clear logic point |
+| metaphor fit | the metaphor explains the point instead of becoming a side joke |
+| public accessibility | a non-specialist can understand the visible situation |
+| narration fit | voiceover adds explanation, not redundant caption reading |
+| composition | image leaves safe space for page text if page text is planned |
+| asset feasibility | the image can be generated or assembled without fragile exact text |
+| continuity | the unit advances from the previous one and sets up the next one |
+| medium fit | it remains a science/explainer page, not an accidental drama scene |
+
+## Small-Batch Strategy
+
+Do not generate every unit first. Pick representative high-risk units:
+
+- one hook or opening unit;
+- one controlling-metaphor unit;
+- one mechanism-explanation unit;
+- one practical-method or dense information unit;
+- one closing or elevation unit when tone is uncertain.
+
+Record the selected batch in `execution-plan.md`, then track unit-level facts in `slides/slides.md`.
+
+## Abstracted Example Shape
+
+```md
+## s03 Unit Spec
+
+- narrative_function: controlling metaphor
+- core_message: The tool is useful only when matched to the weight of the real-world problem.
+- page_copy: two short lines, rendered outside the generated image unless the execution plan says otherwise
+- voiceover_intent: contrast everyday low-risk use with high-stakes decision use
+- visual_task: make the mismatch between lightweight confidence and large external risk visible
+- asset_layers:
+  - background: large-scale risk environment
+  - metaphor object: small helpful tool that looks insufficient at scale
+  - human element: ordinary user facing the environment
+  - overlay: optional page text layer
+- review_focus:
+  - risk scale is obvious
+  - metaphor does not become comic noise
+  - composition supports 16:9 page use
+```
diff --git a/docs/cases/training-ai-ppt-case.md b/docs/cases/training-ai-ppt-case.md
new file mode 100644
index 0000000..1007f72
--- /dev/null
+++ b/docs/cases/training-ai-ppt-case.md
@@ -0,0 +1,162 @@
+# Training AI PPT Case Pattern
+
+This pattern is for training, AI education, customer enablement, internal workshops, and method lectures that need a teachable slide deck.
+
+It is extracted from the old `31_CASE` training AI PPT case. The original topic, prompts, Codex JSON, output paths, and global text prohibitions are not carried forward.
+
+## Use When
+
+Use this pattern when the target is:
+
+- a training deck, course deck, lecture deck, workshop deck, or AI education PPT;
+- a slide sequence that must support live explanation, pause, discussion, and later reuse;
+- a deck where each page is a teaching unit, not a video shot;
+- not a customer proposal whose primary goal is decision conversion.
+
+## Core Difference
+
+Training PPT pages are not scenes. They are teachable units.
+
+Each page should answer:
+
+- What should the learner understand after this page?
+- What misconception or resistance might exist before this page?
+- What example, analogy, contrast, diagram, or exercise lowers the learning barrier?
+- What can the learner do, judge, or remember after this page?
+
+## Learning Path
+
+Common sequence:
+
+```text
+problem entry
+-> concept or model
+-> method frame
+-> example or contrast
+-> practice or migration
+-> summary and action
+```
+
+Not every deck needs all six parts, but the page order should behave like a learning path rather than a list of impressive points.
+
+## Page Granularity
+
+Default rule:
+
+- one page solves one teaching goal;
+- slide copy stays sparse and editable;
+- speaker notes carry explanation, examples, and transition;
+- interaction is included when the page benefits from learner reflection;
+- abstract models need a diagram, matrix, loop, ladder, map, or other visible structure.
+
+Avoid one page trying to explain a concept, prove a case, give a method, run an exercise, and conclude the section at the same time.
+
+## Local Page Spec
+
+For Video Workbench, put this in `slides/sNN/sNN-unit-spec.md` or use it as the basis for that file:
+
+| field | purpose |
+| --- | --- |
+| `unit_id` | `sNN` identifier used by local files |
+| `slide_role` | opening, concept, model, contrast, case, practice, summary, transition |
+| `teaching_goal` | what the learner should understand, change, or be able to do |
+| `core_message` | one sentence that gives the page its point |
+| `slide_copy` | editable title, subtitle, bullets, labels, or quoted line |
+| `layout` | comparison, triangle, matrix, timeline, loop, ladder, map, flow, dashboard |
+| `visual_asset_brief` | background, metaphor, concept visual, diagram base, or scene asset |
+| `speaker_notes` | how the instructor explains the page |
+| `interaction` | question, quick vote, reflection, mini exercise, or none |
+| `transition` | how this page connects to adjacent pages |
+| `review_focus` | what Codex should inspect during iteration |
+
+This is a local execution spec, not a final image prompt or JSON execution package.
+
+## Slide And Asset Layering
+
+Keep these layers separate:
+
+| layer | owns |
+| --- | --- |
+| editable slide text | titles, subtitles, bullet points, labels, formulas, exact wording |
+| layout | structure that controls learner attention |
+| visual asset | background, metaphor scene, illustration, diagram base, icons, texture |
+| speaker notes | explanation, example, pacing, transition, instructor emphasis |
+| interaction | question or exercise that turns listening into retrieval or judgment |
+
+Generated images should not be asked to carry precise deck body copy by default. If the design needs diagram labels or visible text inside an image, document that choice in `execution-plan.md` or the unit review criteria.
+
+## Speaker Notes Style
+
+Speaker notes should do three jobs:
+
+- explain the key concept in plain language;
+- give a concrete life, classroom, business, or product example;
+- bridge to the next page.
+
+Good notes are not page copy repeated aloud. They let the slide stay sparse while still giving the instructor enough material to speak for 1-2 minutes when needed.
+
+## Common Page Patterns
+
+| pattern | use when | layout hint |
+| --- | --- | --- |
+| structural problem | establish why the topic matters | triangle, tension map, before/after |
+| misconception correction | replace a shallow belief with a better frame | split screen, false/true contrast |
+| model introduction | name and explain a reusable model | matrix, loop, layered diagram |
+| method frame | turn concept into steps or checks | flow, ladder, checklist, flywheel |
+| case comparison | show how AI changes a task or judgment | traditional vs AI-enabled |
+| practice page | make learners apply the frame | prompt, scenario, quick exercise |
+| summary chain | close the logic path | timeline, chain, staircase, map |
+
+"Traditional vs AI-enabled" is especially useful for AI training case pages, but it is a pattern choice, not a global rule.
+
+## Review Dimensions
+
+Review drafted or generated pages against these dimensions:
+
+| dimension | pass condition |
+| --- | --- |
+| teaching goal | one page has one clear learner outcome |
+| copy density | slide text is sparse enough to scan and edit |
+| layout clarity | structure helps understanding rather than decorating the page |
+| speaker notes | notes explain, exemplify, and transition |
+| asset layering | visual assets do not replace editable slide text by accident |
+| interaction | any question or exercise has a clear teaching reason |
+| sequence | the page advances the learning path |
+| live usability | an instructor can pause on the page and teach from it |
+
+## Small-Batch Strategy
+
+Do not build the full deck visually before validating the teaching system. Pick representative pages:
+
+- one opening or problem page;
+- one abstract model page;
+- one method-frame page;
+- one case-comparison page;
+- one practice or summary page if interaction or closing tone is uncertain.
+
+Record the selected batch in `execution-plan.md`, then track page-level status in `slides/slides.md`.
+
+## Abstracted Example Shape
+
+```md
+## s08 Unit Spec
+
+- slide_role: model introduction
+- teaching_goal: Learners understand that the model is a decision aid, not a decorative framework.
+- core_message: A usable model changes what people can notice, compare, and improve.
+- slide_copy:
+  - title: short model name
+  - subtitle: one-line use claim
+  - bullets: three editable labels or dimensions
+- layout: center matrix with one highlighted region
+- visual_asset_brief: clean diagram base with subtle learning-path motion; exact labels remain editable in the slide layer
+- speaker_notes:
+  - define the model in plain language
+  - give one concrete classroom or work example
+  - explain why the next page moves from model to use case
+- interaction: ask learners which dimension they currently under-observe
+- review_focus:
+  - model structure is legible
+  - page is not crowded
+  - notes can support live explanation
+```
diff --git a/docs/context-handoff.md b/docs/context-handoff.md
index 97237e3..2be93e4 100644
--- a/docs/context-handoff.md
+++ b/docs/context-handoff.md
@@ -59,6 +59,8 @@ projects/<project-id>/
 
 Use root `handoff/` for repo-level, cross-project, series-level, or context-window handoff notes.
 
+Use `docs/cases/` as the local Codex case-pattern library. It is allowed to extract structure, page or shot granularity, speaker-note style, visual asset layering, and review dimensions from old GPT cases, but it must not re-import old final-prompt, Codex JSON, output-path, or global text-rendering rules.
+
 ## Project Files
 
 `project.md` is a Codex-maintained small note. It should link to intake files and key local execution files instead of duplicating the outline, storyboard, page design, or execution plan.