@kenkaiiii/ggcoder 5.66.4 → 5.67.1

package/assets/motion/skills/motion/SKILL.md

@@ -11,6 +11,91 @@ plan to record before building and the principles: read it before planning a
 new video. Keep the work proportionate to the request: a copy edit does not
 need a new plan.
 
+## Ask first, in plain words
+
+Most users aren't motion designers. They know where the video will be seen and
+what it's for; they can't choose between easing curves or aspect ratios. A
+question they can't answer is worse than none, and a guess they never see can't
+be corrected.
+
+**When to ask.** For a new video from an open prompt, ask once, before planning,
+about what only the user knows and would be costly to change later: where it
+will be watched (it sets shape, length and pace), whether it has music (the
+timing is built on it) and, when the subject suggests they have some, material to
+include. Ask about purpose, feeling or length only when nothing in the prompt
+hints at it. Own everything else: look, colour, type, pacing, transitions.
+
+- Skip anything the prompt, attachments, a brand kit, workspace preferences or
+  `frame.md` already answers. A detailed brief, a shot list or an edit gets no
+  questions.
+- Use one `ask_user` card with at most three questions, each with a recommended
+  answer drawn from the prompt. Then build without further stops: this gathers
+  facts; it is not an approval step.
+- If they have material to include, end the turn with one plain line asking them
+  to attach or paste it, and start when it arrives.
+- Mid-build conflicts (a headline too long for a phone screen, a supplied font
+  that won't fit) follow the same rules: one plain line on the problem, your fix
+  as the recommended option.
+- Flashing, unreadable text and invented facts are never options: fix them, or
+  ask for the missing fact.
+
+**How to word it.** Ask about their world: "Where will people mostly watch
+this?", not "9:16 or 16:9?"; "How should it feel?", not "Which register?".
+Each option is an outcome they'd recognise, and its hint says what it means for
+their video. Use reference points they know (TikTok, YouTube, "like a luxury
+ad"). Keep craft terms out of questions, hints and messages: register, easing,
+LUFS, safe zone, lower third, CTA, fps, kinetic type, loop seam. If one is
+unavoidable, explain it in the same line. If the user writes in those terms,
+answer in them.
+
+**Starting wording.** Adapt it to the prompt and pick at most three.
+
+1. "Where will people mostly watch this?"
+   - Scrolling on a phone: Tall video. Grabs attention right away and works with
+     the sound off.
+   - On a website or YouTube: Wide video. It can take its time; people usually
+     have sound on.
+   - Slides or a big screen: Wide, bold and easy to read from across a room.
+   - As a background loop: A calm, seamless loop for a website or display
+     screen. No sound needed.
+   - Sent to someone: A gift, birthday or memorial. Paced to feel personal, not
+     to grab attention.
+2. "Should it have music?" GG's built-in tracks are all upbeat and cheerful.
+   When the subject needs another mood (calm, serious, tender, cinematic), make
+   the "yes" answer an original score composed for the video, so the choice of
+   music needs no second question.
+   - Yes, add music: I'll choose music that fits and time the video to it.
+   - No, keep it silent: Works anywhere, including feeds where most people watch
+     muted.
+   - I'll add music myself: Silent for now, with a steady rhythm so your music is
+     easy to add.
+3. "Do you have anything it should include?" (pick any): My logo or colours ·
+   My photos or videos · Exact words or numbers · Nothing, start fresh
+4. "What should people get from it?"
+   - Understand something: Explains an idea, a process or some numbers, step by
+     step.
+   - Want to buy or try it: Shows what it does for them and ends with one clear
+     next step.
+   - Hear some news: A launch, an event or a milestone.
+   - Feel something: A mood piece, celebration or tribute, led by feeling rather
+     than facts.
+5. "How should it feel?"
+   - Calm and clear: Gentle movement and time to read. Nothing flashy.
+   - Bold and energetic: Quick cuts, big words, a strong beat.
+   - Playful: Bright and bouncy, with a bit of fun.
+   - Elegant: Slow, precise and spacious, like a luxury ad.
+   - Warm and personal: Soft and unhurried; lets photos and moments breathe.
+   - Serious and respectful: Restrained, for sensitive or factual subjects.
+6. "How long should it be?"
+   - About 10 seconds: One idea, quick to watch.
+   - About 30 seconds: Room for a short story or a few points.
+   - About a minute: Room to explain something step by step.
+
+Illustratively: "30-second vertical launch video for our app, upbeat, logo
+attached" gets no questions. "Make a video for my bakery" gets where it will be
+watched, music and material. "Make a video about black holes" gets where it will
+be watched and how long; infer a curious, clear feel.
+
 ## Choose support only when needed
 
 - `brand-kit`: create, update or apply a reusable brand identity.
@@ -30,14 +115,17 @@ Each video lives in its own workspace folder. Keep one compact `frame.md` beside
 
 ```text
 Output: <duration, dimensions, fps, format>
+Viewer: <where it's watched, sound, purpose; mark what you assumed>
 Brand: <kit or supplied identity | none>
 Sources: <paths/URLs used for facts or assets | none>
 Overrides: <explicitly requested departures | none>
 Limits: <missing/unsupported behaviour and verification status>
 Concept: <the idea it demonstrates; the motif linking scenes>
-Language: <palette roles, type roles, beat, arc, fps>
+Language: <register, palette roles, type roles, beat, arc, fps>
 ```
 
+Record the user's answers in `Viewer` so follow-ups don't ask again.
+
 Reuse it for follow-ups. Do not create a director packet, storyboard, staged
 approval files or a separate brand system. Preserve existing `DESIGN.md`, brief
 or storyboard files if a legacy project has them.
@@ -84,6 +172,7 @@ them.
 Fix concrete defects and render. For a targeted fix or small edit, spot-check
 the changed moments first (`spot: true`), then run one full check on the export
 you deliver. An unchanged export needs no repeated checking unless its hold plan
-changed. Deliver the MP4, reveal it and state real limits.
+changed. Deliver as `video-qa` describes: reveal the MP4, write the delivery
+message with real limits as your final message.
 Sampled frames are not full playback or audio listening; technical success is
 not proof of visual quality.

package/assets/motion/skills/video-qa/SKILL.md

@@ -19,9 +19,9 @@ Call `motion_check` with:
 - `range`: only for an export longer than 180 seconds or a targeted diagnostic, a start/end range of at most 180 seconds. Report the inspected range honestly; do not claim full-video visual coverage.
 - `spot`: true for a quick check of a targeted fix or small edit. Put short `windows` around the moments you changed, at most 240 rendered frames in total (4 s at 60 fps). The layout check then covers every rendered frame inside them, far faster than the full check, while the pixel, hold and audio checks still cover the whole export. A spot result is never delivery verification: once it is clean, run the full check (without `spot`) once on the export you deliver.
 
-The tool runs HyperFrames `check` (which already includes lint), decoded-pixel analysis with `motion-check.mjs` including canvas/WebGL, and audio analysis only when audio exists. It returns technical results and actual rendered overview, phone-size and consecutive-frame images **to you**, the working agent.
+The tool runs HyperFrames `check` (which already includes lint), decoded-pixel analysis with `motion-check.mjs` including canvas/WebGL, a flash check of the whole export against the WCAG 2.3.1 limits, and audio analysis only when audio exists. It returns technical results and actual rendered overview, phone-size and consecutive-frame images **to you**, the working agent.
 
-Do not precede or follow it with another lint/check/audio/frame-extraction checklist. Do not call the legacy `motion_review` prepare/submit workflow. No subagent, separate model critique, approval score or chapter registration is needed.
+Do not precede or follow it with another lint/check/audio/frame-extraction checklist. Diagnosing a specific failure it reported, or looking at a few frames while building, is part of the work, not a second check. Do not call the legacy `motion_review` prepare/submit workflow. No subagent, separate model critique, approval score or chapter registration is needed.
 
 ## 2. Inspect what was returned
 
@@ -41,7 +41,9 @@ If the tool fails, its check details list each problem with where and when it oc
 
 A failed check or visibly wrong output warrants a targeted fix, a new versioned render and a spot check of the fixed moments, then one full check once they are clean. An unchanged export does not need checking again unless you corrected its hold plan; that re-check reuses the passing source audit, so it is quick. Do not iterate toward subjective perfection or route the result to another reviewer. Report an unresolved blocker as draft/unverified rather than looping indefinitely or declaring success.
 
-The tool measures audio and rejects non-finite levels or clipping; it does not normalize the file. Follow the user's delivery loudness target when they give one. Do not add audio to silent work or force every supplied animation through a generic -14 LUFS mix.
+The tool measures audio, reports its integrated loudness and true peak, and rejects non-finite levels or clipping; it does not normalize the file. Follow the user's delivery loudness target when they give one. Do not add audio to silent work or force every supplied animation through a generic -14 LUFS mix.
+
+A flash failure names when it happens and how fast. Retime or soften that moment: at most three light/dark or red swaps in any second, a smaller flashing area, or a smaller brightness difference. Never ship it, and never mark it as a hold to get past it.
 
 ### Intentional holds
 
@@ -59,10 +61,29 @@ When a hold is stale, the check lists where the pixels actually freeze; correct
 
 ## 4. Deliver
 
-Deliver the actual versioned MP4, then reveal it:
+Deliver the actual versioned MP4 in this order. The written message is what the user reads to understand what they got, so it is your final message: no `ask_user` card at delivery, which would come before the message and hide it.
 
-```bash
-<node> "<motion bin>/reveal.mjs" renders/<file>.mp4
-```
+1. Reveal the file:
+
+   ```bash
+   <node> "<motion bin>/reveal.mjs" renders/<file>.mp4
+   ```
+
+2. Write the delivery message as your final message, in plain words:
+   - One bold line on what they got, in their words: length, shape, where it fits, how it ends.
+   - One line on anything you assumed, so a wrong guess is easy to spot.
+   - What the checks mean for their viewers, never the standard or tool names; those stay in `frame.md`. Mention only checks that actually ran and passed.
+   - What couldn't be checked, plainly. Do not claim full playback or audio listening from sampled images.
+   - After a new video, one closing sentence naming the two or three changes they're most likely to want. Don't make them unasked.
+
+Illustrative delivery message, to adapt rather than copy:
+
+> **A 15-second tall video for Instagram, with upbeat music, ending on your logo.** I assumed it's for people who don't know the shop yet, so it leads with the bread rather than the name.
+>
+> It's safe for people sensitive to flashing lights, all the text fits on screen with enough contrast to read, and the sound stays clean at its loudest moments. I checked it frame by frame, but I can't watch it the way you will, so play it once on your phone before you share it.
+>
+> If you'd like, I can add your address and opening hours, use your real logo, or make a wide version for your website.
+
+If they gave a loudness target, say whether it was met. Report what you designed for but no check measures, such as keeping text clear of Instagram's or TikTok's buttons, as your choice ("I kept the text clear of Instagram's buttons"), never as a check result. If something couldn't be checked: "I couldn't listen to the sound, so play it once on your phone first."
 
-State concrete remaining limits. Do not claim full playback or audio listening from sampled images. No automatic posters, share copy, extra formats or launch packages.
+No automatic posters, share copy, extra formats or launch packages.

package/dist/core/agent-session.js

@@ -1157,7 +1157,14 @@ export class AgentSession {
                         if (call.sourceSnapshot === null)
                             this.verificationGate.requireFreshVerification(true, event.args.command);
                     }
-                    else {
+                    else if ((classification.accepted && event.args.persist !== true) ||
+                        (!classification.accepted && classification.mayMutate)) {
+                        // Flag the workspace unknown only when tool_call_end can resolve
+                        // it: a bounded check records pass/fail, a file-rewriting command
+                        // bumps the revision. An unrecognized read-only check (`biome ci`)
+                        // or a persistent-shell run records nothing at the end, so
+                        // flagging it left verified work Unverified forever — and
+                        // autopilot silently refused every later turn.
                         this.verificationGate.requireFreshVerification(!classification.accepted && classification.mayMutate, event.args.command);
                     }
                     await this.persistVerificationState();