forgeax-scriptable-pack-review

Scriptable Pack is a code-authored asset format; procedural describes content created by rules and algorithms. Build-time *.pack.ts, directly generated runtime assets, and executable runtime generators are eligible for review. A valid Pack, successful execution, or accepted publication can still wrap prefabricated data or Base64. Assess format and procedural provenance separately.

This file includes the Engine contract and historical Palace evidence, so it can be shared alone. Repository ownership is Engine skills/forgeax-scriptable-pack-review; Harness distributes shared workflow skills.

Review intake

Record the following conditions, adopting choices the user already supplied. If the required type is unspecified, ask while continuing format and closure checks; do not issue an overall PASS before it is confirmed.

[!IMPORTANT] Public generation parameters belong to the delivered interface. Internal function arguments, build context, constants, environment variables, output shader parameters, and camera controls do not establish generator classification. A public effective seed qualifies; a generator with complete defaults remains a generator.

Record required type and actual interface type independently. A mismatch is FAIL; do not reclassify the requirement. Ineffective public parameters are a generator defect, not grounds to review it as a fixed asset. A fixed instance's generation capability belongs to its parent; determine whether the reviewed delivery includes that parent's source and dependencies.

This skill produces review conclusions. Repairs, conversions, and publication follow the user's task scope. For first inspection or version differences, compare the embedded contract with the target version's definitions, validators, and actual production path. Historical evidence never establishes current API behavior or a delivery's PASS.

Production paths

Import's RuntimePackProducer owns runtime production; App assembles it into existing asset services. Invoke production explicitly outside asset loading and ECS frames. Consumption retains Registry/GUID ownership. Calling a geometry function or rendering temporary objects does not qualify Runtime Pack delivery.

Classify interface and execution path independently. A fixed recipe may compute runtime data before admission; public parameters on direct data generation still require generator checks. producer.generate requires an admitted anchor with nonempty parameters. Admitting a parameterless definition does not generate fixed assets; do not add meaningless parameters to fit the API.

Common checks

Mark each applicable item PASS / FAIL / BLOCKED / N/A with file locations or execution evidence. Explain N/A applicability; unknown or unexecuted work is not N/A.

Compare actual payloads and refs, not only package IDs/sourceKeys. Document exclusions for nonsemantic tool metadata. Floating tolerances require a target-contract basis and must not conceal differences.

Procedural content versus disguised data

Judge which information determines the content, not extension, code size, array length, compression ratio, or the presence of loops.

1. Search encoded strings, numeric tables, TypedArray initializers, decoding/decompression, file/network reads. Treat hits as leads; trace consumers before deciding.
2. Identify rules, semantic recipes, and already-stored results for each key output; inspect both scene composition assets and layout sources.
3. In an isolated copy, test suspicious tables/caches against their claimed generating chain; meaningful dimensions/sampling-density changes may expose recomputation. This experiment neither makes a fixed asset a public generator nor proves every input.
4. Record procedural parts, data parts, and external dependencies separately. A small procedural object cannot qualify a prefabricated main delivery; closure is not provenance.

With auxiliary data allowed, check each use against the user's prior authorization and report "procedural + data mixture"; P2 still applies. Auxiliary data cannot replace the promised generating subject without bounds. Do not relax policy after discovering failure. A selected sub-output review covers all its dependencies and limits conclusions to that scope.

Type-specific checks

Procedural asset

Procedural asset generator

G3 proves parameter effects; P1/P2 establish procedurality. For seed inputs, check same-seed reproduction and representative different-seed changes without requiring every seed to be unique. Direct library calls do not replace G6's formal interface.

Runtime checks

Apply T1-T6 to runtime or two-stage deliveries; mark pure build-time delivery N/A. Subchecks depend on the promised capability; unknown or unexecuted work remains a gap.

Recoverable direct-asset snapshots can contain complete data without a delivered procedural algorithm: T4 does not replace C3/P1. For explicitly temporary content without persistence promises, T4 may be N/A but C3 still requires cold generation from delivered algorithms/legal inputs. Two-stage promises require separate evidence for both paths.

Engine contract

Checked against Engine revision df4c86bf12bf117ed229e2721e98d60ad1b0d7a0 on 2026-10-14. These are source-contract facts, not runtime acceptance for a reviewed delivery. Recheck the target revision's actual behavior when it differs.

Source locations in an Engine checkout: packages/pack/src/pack-authoring.ts, packages/pack/src/program.ts, packages/import/src/runtime-pack.ts, runtime-pack-content.ts, runtime-pack-snapshot.ts, and packages/app/src/runtime-packs.ts. Detailed contracts: Pack, Import, App, DevKit.

Historical Palace evidence

Engine revision 2b613d2209e4335c2eab2c75ebaeb2eb269b2879, path apps/showcase/palace. These source observations were not a complete executed Palace review. They do not establish the current showcase's contents or runtime API. Start with the pinned Palace README for build instructions and asset provenance.

For this historical whole-package strict-policy scope, known map/image inputs fail provenance. The building rules remain useful procedural examples. Allowing auxiliary data still requires all other checks before PASS.

Conclusion and report

Produce a concise Markdown report; no additional JSON is required:

# ForgeAX procedural asset review

- Object / revision / delivery scope:
- Required type / actual interface type:
- Execution stage / production path:
- Data policy / authorized auxiliary inputs:
- Engine / SDK / source revision / actual Host / realm / dev-build environment:
- Overall: PASS | FAIL | BLOCKED

## Check results

| ID | Status | Evidence location / command and observed result | Issue / correction direction |
|:--|:--|:--|:--|

## Provenance and dependencies

| Output | Generating rules | Recipe / original data / cache | Delivery and resolution |
|:--|:--|:--|:--|

## Execution evidence and coverage limits

- Cold production / consumption / repetition; generator contrasts and boundary results.
- Runtime formal prepare/admit/generate, publication/current execution, cold snapshot recovery, withdrawal/cleanup, applicable platform evidence.
- Unexecuted checks, uncovered combinations, auxiliary data, conclusion scope.

Separate format, closure, procedural provenance, parameter, and runtime delivery findings. Partial passes never replace the overall conclusion. Source inspection cannot prove cold production, appearance, legal-input coverage, or recovery; examples and Engine tests cannot qualify another delivery.