Skip to content

WIP: Feat/daydream implementation - #14

Open
vinkent420 wants to merge 27 commits into
mainfrom
feat/daydream-implementation
Open

vinkent420 wants to merge 27 commits into
mainfrom
feat/daydream-implementation

Conversation

@vinkent420

Copy link
Copy Markdown
Collaborator

Pull request

Outcome

Make Daydream the mandatory first creative step of every workshop start <inventor> cycle and turn it into a world-informed, Taste-governed creative product thesis, not an ordinary idea generator or another product-run stage.

Each Dream now:

  • observes current-world signals through verified live-search activity;
  • applies the selected Inventor’s exact Taste and specialist skill bundle;
  • checks prior work, the cross-Inventor portfolio, Design Vault guidance, and factual downstream outcomes;
  • explores and falsifies materially different interaction families;
  • seals one provenance-bound schema-v3 thesis with an observable proof plan and route floor; and
  • teaches later Dreams from actual Make, Playtest, Release, publication, and Factory outcomes.

The predictive Daydream Judge is removed from the active runtime. Replay against real outcomes showed that it rejected both failed builds and published products, making it an uncalibrated admission wall. Its useful nine dimensions remain as an Inventor pre-commit audit inside the single Daydream Goal. Historical verdicts remain readable but no longer gate Wish creation.

Ownership

  • Owning component: daydream
  • Other affected components: workflow, cli, repository
  • Primary DRI: @deehw
  • Backup or second reviewer: vacant
  • Risk: critical (workflow and repository contracts are critical; daydream and cli are standard)

Change class

  • Component implementation
  • Cross-component contract
  • CLI
  • Inventor specialist bundle or custom tool
  • Product-run constitution or workflow skill
  • Skill or locked dependency
  • Schema, canonical bytes, or artifact identity
  • Durable state, event, migration, receipt, or external effect
  • Documentation, governance, CI, packaging, or release
  • Security-sensitive change

Current and resulting behavior

Before:

  • Daydream produced a compact schema-v1 idea from Taste, a random seed, prior work, and a small notebook.
  • It had no mandatory real-time world observation, exact specialist-method binding, cross-Inventor portfolio, Design Vault context, or full downstream lineage.
  • Creative learning was largely lexical and static.
  • The experimental branch added a separate predictive Judge, but outcome replay showed that this Judge also rejected products that had successfully passed Workshop and been published.

After:

  • Daydream is the mandatory first creative step for workshop start; direct workshop wish remains the separate path for an already-authored human Wish.
  • One native Daydream Goal produces one schema-v3 creative thesis.
  • The host requires observed live-search telemetry and validates exact observation times, source URLs, Taste excerpts, route compatibility, learning hashes, and portable-schema parity.
  • The selected Inventor’s exact custom-agent identity, Taste, and declared skill trees are materialized and hash-bound.
  • Prior work, cross-Inventor portfolio history, advisory Design Vault evidence, notebook memory, and exact downstream outcomes are separate provenance planes.
  • The thesis preserves opportunity, action, response, payoff, anti-generic signature, proof mode, kill criteria, Invent freedom, and minimum capable route.
  • New Dreams have no predictive Judge turn or verdict gate. Historical verdict-bearing records remain readable and non-authoritative.
  • Daydream-originated product runs emit exact lineage through Invented, Made, Playtested, Release, product artifact, and Factory identities where available.
  • Start, failure, interruption, completion, and resume outcomes are appended as bounded host-observed facts for later Dreams.

Explicitly out of scope:

  • Daydream does not choose exact mechanisms, dimensions, materials, tolerances, components, or construction; those remain Invent or Spark Make responsibilities.
  • Python does not generate, fan out, semantically rank, or score creative candidates.
  • No Python reward loop, model judge, second agent framework, or extra product-run stage is introduced.
  • This PR does not modify Inventor Taste or specialist bundles.
  • It does not claim physical feasibility, customer demand, publication success, or “best in the world” from unit tests or model self-evaluation.
  • No new authenticated manufacture, publication, payment, postage, or carrier effect is added.

Boundaries and contracts

  • Public contract added or changed:

    • workshop.daydream schema-v2/v3 thesis models and portable validation.
    • Opportunity, WorldScan, WorldSignal, Experience, ProofPlan, and LearningTrace.
    • DaydreamProvenance and exact context identities.
    • Cross-Inventor portfolio projection.
    • RunOutcomeMemory, remember_run_outcome, and remember_resumed_outcome.
    • Expanded native-run receipt lineage and publication identity fields.
    • Wish context binding for Daydream, idea, provenance, Inventor, and route identities.
  • Components consuming it:

    • cli starts or reloads a sealed Dream and records run outcomes.
    • workflow emits checkpoint-verified lineage in native-run receipts.
    • Later Daydream Goals consume bounded notebook, portfolio, Vault, and outcome projections.
    • repository packaging includes the exact prior-work catalog.
  • Dependency direction:

    • CLI imports the public workshop.daydream and workshop.workflow APIs.
    • Workflow owns lifecycle sequencing and exposes verified receipt lineage.
    • Daydream consumes public Inventor, Vault, Manager, and Wish contracts.
    • Neither Inventor bundles nor Python helpers become lifecycle orchestrators.
  • External ports or effects:

    • Native Manager live web search is observed as a required tool event.
    • GameVault export is read-only, advisory, and may be unavailable.
    • External pages remain untrusted evidence.
    • No new authenticated or physical effect is executed.
  • Durable formats read or written:

    • work/IDEA.json: schema versions 1–3; new writer uses v3.
    • Sealed Daydream: schema versions 1–3; new writer uses v3.
    • PROVENANCE.json: schema v1.
    • NOTEBOOK.jsonl: historical versions retained; new learning records use v3.
    • OUTCOMES.jsonl: versions 1–2; new writer uses v2.
    • Native receipt lineage: schema v1.
    • Daydream-originated Wish context with exact hashes and frozen route.
    • Packaged src/workshop/daydream/prior_work.json.
  • The change stays in its owning source and mirrored test directories.

  • Components import public contracts, not sibling private implementations.

  • Workflow remains the only stage sequencer.

  • Product work remains one persistent native session per Wish and one active Codex Goal per cognitive stage attempt; Python does not own the improvement loop.

  • CLI and inventor code depend on Workshop; Workshop does not import them.

  • No new core, foundation, common, or utils dumping ground was added.

Conditional review

Inventor

  • Inventor ID and Taste boundary: all eligible schema-v8 Inventors; no individual Inventor or Taste changed.
  • Declared Codex skill trees: loaded from each selected Inventor’s exact manifest and materialized without modifying their bytes.
  • Root TASTE.md remains canonical and workflow-bound.
  • The schema-v8 manifest and exact skill-tree hashes match the submitted bytes.
  • The run materializes identity, Taste, and skill bindings only through .codex/agents/.
  • Inventor scripts are deterministic specialist tools, not agent or lifecycle orchestration.
  • Shared Workshop machinery is reused instead of copied.

Skill or dependency

  • Owner component: not applicable
  • Source URL and exact revision: no new dependency
  • License and provenance record: no dependency change
  • Lock or fingerprint change: none in this PR
  • Executable modes and installed bytes were verified.
  • A lock change represents an intentional byte change, not only a move.

Schema, artifact, or durable state

  • Format and old/new versions:
    • Idea and sealed Daydream: v1 → readable v1/v2/v3, with v3 as the new writer.
    • Notebook memory: historical entries remain readable; new learning entries use v3.
    • Outcome memory: readable v1/v2, with v2 as the new writer.
    • Native lineage receipt: new v1 contract.
  • Reader/writer compatibility:
    • Existing schema-v1/v2 ideas, seals, notebook entries, and historical verdicts remain readable with their original identities.
    • New records do not require or create a predictive verdict.
    • Saved historical dream-again verdicts no longer prevent build admission.
  • Canonicalization or hash impact:
    • Existing canonical records and hashes are unchanged.
    • New schema-v3 thesis and seal hashes intentionally bind the expanded content.
    • Provenance binds the exact prompt, constitution, Taste, Inventor binding, skill bundle, Vault binding/snapshot, prior work, portfolio, notebook/outcomes view, finalizer, portable schema, world scan, prior art, route, and Manager specification.
  • Rollback or reconciliation path:
    • No existing record is rewritten or migrated in place.
    • Outcome logs are append-only and content-hashed.
    • An older binary will not consume newly written v3 records; preserve those bytes and roll forward to the v3 reader rather than down-converting them.
    • Resume receipts reconstruct and verify the original Daydream lineage before appending another outcome.
  • Existing state and evidence remain readable through tested readers.
  • Historical records, receipts, hashes, and artifact bytes were not rewritten.
  • Malformed, unknown, partial, retry, and ambiguous outcomes fail truthfully.

Outside or physical effect

  • Effect and authorization boundary: no new authenticated or physical effect. Native search and optional GameVault export are read-only inputs; Factory fields are copied only from existing host-verified receipts.
  • Idempotency key and receipt binding: no new effect invocation; outcome facts bind the Wish, Daydream, checkpoint, stage artifacts, and publication receipt identities.
  • Ambiguous-outcome behavior: malformed or inconsistent lineage is rejected instead of being converted into learning evidence.
  • Intent is durable before execution and retries cannot duplicate the effect.
  • Offline tests use explicit fakes and do not claim live readiness.

Verification

PYTHONPATH=src python -m pytest \
  tests/daydream \
  tests/end_to_end/test_daydream_learning_loop.py \
  tests/cli/test_cli.py \
  tests/workflow/test_daydream_lineage.py \
  tests/architecture/test_component_import_graph.py \
  tests/packaging/test_package_data.py \
  tests/invent/test_vault.py \
  tests/invent/test_vault_tools.py \
  tests/workflow/test_budgets.py \
  tests/workflow/test_native_host.py \
  -q

292 passed in 42.19s

python tests/packaging/installed_wheel_cli_acceptance.py

installed-wheel-cli: ok

git diff --check origin/main...HEAD

No output; passed.
  • Narrow component or CLI tests
  • Contract/integration tests for every affected boundary
  • Full repository test suite
  • Architecture dependency checks
  • Installed wheel and resource smoke tests when packaging/resources changed
  • Skill/schema/runtime-asset identities when applicable
  • Secret and provenance checks
  • git diff --check

Compatibility and release note

  • Added/updated changes/daydream-mvp.added.md
  • No changelog required; reason:
  • Breaking Python API: no intended removal from the main-branch public API. New Daydream writers produce v3 records, and active runtime Judge APIs from the experimental branch were retired before merge.
  • Durable compatibility impact: additive versioned thesis, provenance, notebook, outcome, and receipt-lineage formats. Existing v1/v2 and historical verdict-bearing records retain their exact bytes and identities.
  • Migration or deprecation window: no in-place migration. Versioned readers preserve historical state; new v3 state requires the v3-capable reader.

Reviewer guide

Start with these files:

  1. src/workshop/daydream/prompt.py

    • Confirms the creative boundary, live-world research, divergent exploration, nine-part pre-commit audit, and learning from real outcomes.
    • Verify there is no predictive Judge turn or Python semantic scoring.
  2. src/workshop/daydream/contracts.py and src/workshop/daydream/schema.py

    • Review v1/v2/v3 compatibility, portable-finalizer parity, evidence bounds, route floor, learning hashes, and exact provenance.
    • Historical verdict support must remain read-only compatibility, not admission authority.
  3. src/workshop/daydream/native.py

    • Review exact Inventor/Taste/skill materialization, read-only Vault handling, live-search telemetry, temporal checks, private state, provenance construction, and one-Goal execution.
    • Confirm credentials and untrusted external instructions cannot enter the workspace as authority.
  4. src/workshop/daydream/outcomes.py and src/workshop/workflow/native_run.py

    • Review allowlisted outcome facts, checkpoint-verified artifact lineage, publication identity readback, append-only memory, and resume behavior.
    • Python records facts but does not derive a creativity score or rewrite Taste.
  5. tests/end_to_end/test_daydream_learning_loop.py

    • Demonstrates that an actual downstream failure reaches the next Dream by exact identity and that the repaired thesis crosses into Wish unchanged.

Primary tradeoff: removing the predictive Judge may allow more hypotheses to consume build time, but avoids a second uncalibrated native session that produced false negatives on already-published products. Quality control remains split honestly: Daydream performs rigorous pre-commit falsification; Invent/Make/Playtest/Release provide the evidence; later Dreams learn from those exact outcomes.

Keep Daydream as the mandatory creative-thesis step, retire the uncalibrated predictive Judge, and learn from exact downstream outcomes while preserving the latest shop, budget, CAD, and Pearlturn work from main.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant