k9i-0 Develop Flutter Scene Extensions
Read the root AGENTS.md, then open only the directly relevant ground-truth
document it names.
Workflow
- Identify whether the change belongs to generic glTF/Scene behavior, the VRM extension layer, or a non-published playground.
- Keep generic glTF behavior in the pinned Flutter Scene fork. Keep VRM types
in
packages/flutter_scene_vrm. Keep cameras, UI, platform channels, and game state in playgrounds. - Add targeted tests with each behavior change. Do not promote parsed-only features to supported status.
- For UI or scene behavior, run the app through Dart MCP and verify the state through Marionette custom extensions. Capture a screenshot when appearance changes.
- Run
mise exec -- dart run tool/check.dart. Use--buildwhen platform or renderer compatibility can change. - Update public API docs, the feature matrix, changelog, and upstream plan when their claims change.
Asset changes
Before adding an asset, record its source URL, exact revision, SHA-256, license,
attribution, redistribution permission, and modification permission. Keep the
license beside the asset and update THIRD_PARTY_NOTICES.md. Do not infer that
a repository code license covers models, textures, audio, logos, or mascots.
Release and upstream boundary
Keep flutter_scene_vrm at 0.x and publish_to: none while it has a Git
dependency. Prepare upstream work as small generic glTF pull requests with
focused tests. Publish only after the package resolves exclusively through SDK
and hosted pub.dev dependencies.
Read references/commands.md when choosing validation commands or MCP extensions.