Skip to content

program.md

Latest commit

 

History

History
154 lines (112 loc) · 3.53 KB

program.md

File metadata and controls

154 lines (112 loc) · 3.53 KB
Raw

Dream Claw program

Dream Claw is a CPU-safe creative research loop.

It borrows the shape of karpathy/autoresearch, but not the GPU training part.

Autoresearch does this:

try model change
→ train for fixed time
→ score val_bpb
→ keep or discard
→ log result

Dream Claw does this:

try creative change
→ score the launch pack
→ find the weakest part
→ repair that part
→ rescore
→ keep or discard
→ log proof

Goal

Turn a rough creator idea into a better launch pack and prove what got better.

Dream Claw should not only make output. It should show the work changed for a reason.

Fixed rules

These rules are the guard rails. Do not change them during a run.

  1. Keep the run small and fast.
  2. Use text, browser UI, and local files. No GPU required.
  3. Score before and after each repair.
  4. Fix one weak point at a time.
  5. Ask a human when the choice needs taste or trust.
  6. Save the before state, critique, repair, after state, score change, and proof ledger.
  7. Do not fake live collection, human review, or external proof.

Editable work

The agent may edit:

  • launch message
  • headline
  • bullets
  • proof pack text
  • post thread
  • demo script
  • README copy
  • browser demo copy

The agent should not change the scoring rules just to make the score look better. That is cheating, and worse, boring.

Scorecard

Use simple 0 to 10 scores.

hook: does it catch attention fast?
clarity: is the idea easy to understand?
proof: does it show real work and real value?
look: is it clean and easy to read?
pace: does it move well?
readme: can a judge understand it in under 1 minute?

The best score is not always the fanciest output. A clearer plain version can beat a pretty vague version.

Loop

Run this loop for each creative pass:

  1. Read the creator brief.
  2. Make or load the current draft.
  3. Score the draft.
  4. Pick the weakest score.
  5. Write a short critique of that weak point.
  6. Decide the route:
    • agent repair for clear text, order, format, missing detail, or broken files
    • human taste check for brand voice, final promise, name, trust, safety, or sales claim
  7. Apply the repair or record the human task.
  8. Rescore the result.
  9. Keep the change only if it improves the pack or makes the risk clearer.
  10. Save the proof ledger row.

Output files

A good run saves:

runs/<run_id>/brief.md
runs/<run_id>/before.md
runs/<run_id>/critique.md
runs/<run_id>/after.md
runs/<run_id>/proof_pack.md
runs/<run_id>/proof_ledger.jsonl
runs/<run_id>/human_tasks/*.md

The current static demo still uses demo/. The next build should move fresh runs into runs/<run_id>/ and keep runs/latest/ as a pointer or copy.

Keep or discard

Keep a repair when:

  • the score improves
  • the message is clearer
  • the proof is stronger
  • the human task is more precise
  • the risk is easier to see

Discard or rewrite when:

  • the score improves only because the rubric changed
  • the copy sounds fake or too polished
  • the claim gets bigger without proof
  • the output becomes harder to explain
  • the demo depends on slow cloud video or GPU work

Public story

Do not pitch this as a GPU research system.

Pitch it like this:

Dream Claw improves creative work in a loop, then proves what changed.

Shorter:

Creative agents need proof, not just output.

Next implementation target

Build a live-feeling local demo:

brief
→ draft
→ score
→ weak point lights up
→ repair runs
→ score improves
→ proof ledger locks

The demo should run on ordinary CPU hardware and open in a browser.