Tasteforge Video

TasteForge Video

For the complete standalone creative pipeline, use taste-distillation then taste-application. Those ECC skills ship their Python scripts directly: measure references, generate or pass through existing takes, grade, cut, composite, verify, and hand off to Blender and Resolve. No separate video repository is required for that flow. This skill documents ECC's packaged offline engine and its strict evidence contract.

TasteForge turns "make it feel like this reference" into a repeatable, inspectable workflow: interview taste, distill it into a structured style pack, validate the pack, apply its measured cadence and look to local media, and export an editable timeline. The canonical implementation is the tasteforge package shipped inside ECC at skills/taste-application/scripts/tasteforge/. Ito-Markets/ito-video is an example project that consumes the packaged ECC engine.

When to Use

• The user asks to interview for video taste before any footage is made ("ask me about the look", "interview me about aesthetic direction").
• The user wants to distill an aesthetic into structured constraints — a reusable style pack rather than vibes ("turn these references into a pack").
• The user wants to validate a style pack (is the metadata complete, schema-valid, cadence measured, spec distilled?).
• The user wants to apply a style pack to local footage — plan a cut from the pack's measured cadence over local clips, deterministically.
• The user wants to export EDL/FCPXML — an editable, frame-exact handoff to DaVinci Resolve / Premiere / Final Cut.
• The user asks for a generated-media provenance audit — where did this pack, spec, or cut come from; what was measured locally versus generated by a provider; what was dry-run.
• The user asks to discover or plan file-driven multimodal image, video, or 3D-asset outputs from local reference files, including separate manifests, subject-anchored CV effects, or Resolve effect recipes.
• The user mentions TasteForge, style packs, flashethereal, taste distillation, cadence/rhythm planning, multimodal discovery, distill/apply workflows, or a taste interview for video.

Local Deterministic Operations vs Provider Generation

This boundary is the core of this compatibility skill. Its operations are local, deterministic, and offline:

Provider generation must fail closed in ECC. Any live Fal (or other provider) call — generating shots, minting prop meshes, hosted VLM distillation — requires explicit separately authorized execution under a separate lane with its own review. In this compatibility lane, ECC never calls Fal, never reads any API key or other credentials (FAL_KEY included), uploads no media, and mutates no provider account state. When a request needs provider generation, state exactly that boundary, run the local half (interview, pack validation, planning, export), and stop.

Never claim a Fal workflow is saved. A local reference to a Fal endpoint, model id, or dry-run URL (they appear inside pack metadata) is reference-only: it never means a provider-side workflow was saved, persisted, or is authorized to run. Anything produced offline carries dry-run/dry_run semantics — say "dry-run spec" or "deterministic plan", never "generated by the model".

Canonical Implementation

• Repository: affaan-m/ECC; Python distribution ecc-tasteforge, package directory skills/taste-application/scripts/tasteforge/. Install from the extracted ECC package with python3 -m pip install ./skills/taste-application/scripts. The example project Ito-Markets/ito-video pins a specific ECC commit.
• CLI: python3 -m tasteforge <command> — provenance, inspect, validate, interview, distill, apply, export, multimodal. --live flags exit with code 2 and refuse.
• Schemas are the contract: taste profile, pack manifest, grade, cadence, spec, timeline events, application reports (provider is enum-locked to "none"; dry_run to true).
• Recovered-source lineage and deliberate exclusions live in the repo's skills/taste-application/SOURCE.md. Run python3 -m tasteforge provenance for the machine- readable version.

Use the installed ECC engine for local deterministic commands and interpret its JSON. Install the packaged engine if absent; do not reconstruct its logic inline. taste.resolve is a compatibility import of tasteforge.resolve, so the creative scripts and example project share one verified Resolve adapter.

The python3 -m tasteforge CLI uses the installed ecc-tasteforge distribution. The standalone taste-distillation and taste-application scripts ship in ECC's opt-in media-generation module with their own Python requirements. Neither path requires publishing the user's repository or media.

Before resuming a saved checkout, record its commit and inspect local branches and worktrees for later implementation fixes. Run the canonical package's tests and python3 -m tasteforge apply --help; ECC's text and fixture tests do not prove that the selected Python checkout implements this contract.

Chaining the Creative Skills

Use only the stages the project needs. The taste skill's historical angelcore/cloud-trance palette and beat grammar are optional creative examples; they must not override the current brief or merge distinct numbered genres. Use each genre's actual references for its direction, including 3D Cyber Glitch and Fluid Sketch. TasteForge does not replace these skills or require every renderer. Keep 3D materials, geometry, wireframe behavior, motion, and composition explicit in the genre signature. A 3D request manifest is a plan for an asset; it is not a mesh. A subject-anchor descriptor names a tracking requirement; it is not evidence that a subject was detected or tracked. Inspect actual tracks, track-loss behavior, and rendered subject frames before claiming that CV effects have been applied reliably.

Workflow

1. Interview (interview): collect answers for the look axes — palette, grain, lighting, focal length, camera motion, subject framing, grade, mood adjectives, avoid list — and separately the content brief. Keep look and content separate; merging them is the classic failure.
2. Distill (distill): map the profile onto the spec schema offline, embedding the pack's measured grounding (black/white point, contrast, per-zone chroma, palette, cut rhythm) when a pack is supplied. The result is a dry-run spec: deterministic, provider "none".
3. Validate (validate / inspect): check the pack against its schemas; report errors vs warnings (missing stills in a metadata-only pack are a warning, not an error).
4. Apply (apply): plan shot durations from the pack's measured cadence (seeded, deterministic) over the user's local clips; produce the application report and frame-exact timeline events.
5. Export (export): write CMX3600 EDL + FCPXML 1.9 with rational, NTSC-safe times for import into a real NLE.
6. Audit (provenance): report lineage — recovered-source digests, generation history, fixture provenance, provider references as pointer-only records.