Force Semantics

"--force should redo the work you meant, not blow away the guard that protects your money."

The Escape Hatch Everyone Reaches For

Layered identity is great until the day you actually want to redo something the system thinks is done — you improved a prompt, you want fresh summaries. So you reach for --force. And here's the design question that separates a safe tool from a footgun: what should --force actually do? The lazy, dangerous answer is 'ignore every identity and redo literally everything.' On a pipeline where some of that 'everything' costs money per call, that blunt force would blindly re-pay for audio it already has transcripts for. The escape hatch becomes a way to accidentally spend a fortune.

Force Is Scoped, Not Total

Recall's --force is deliberately surgical. It invalidates exactly the layers you meant and leaves the money guard intact:

It creates a fresh execution identity — a new batch and job — so the pipeline genuinely re-runs instead of short-circuiting on 'already done.'
It regenerates downstream artifacts — the summary, the title — because those are cheap to recompute and are usually what you're forcing for.
But the content-addressed paid-call identity is unchanged. Identical audio under identical config still hashes to the same paid key, still finds the completed ledger row, and still reuses the stored response. No new POST. No new charge.

So a normal --force gives you what you actually wanted — a re-run and fresh derived outputs — without touching the one thing that costs money. A genuine paid rerun of identical content is not reachable through the generic force flag. It requires a separate, explicit act: either a real change in configuration lineage (which legitimately produces a new paid identity) or an explicit operator authorization that says, in so many words, 'yes, pay for this again.' And the narrowest force of all — a title-only force — re-runs just the title prompt on the existing summary: it reads no video, prepares no audio, and spends nothing.

The Principle: Force Respects the Boundary It Shouldn't Cross

The general lesson is about how to design a 'redo' override at all. A force flag that means 'ignore all safety' is astonishing in the bad way — it does far more than the user pictured, and the surprise is expensive. A well-designed force is scoped: it invalidates precisely the layers the user wants regenerated and explicitly refuses to cross the irreversible or costly boundary without a separate, louder opt-in. Version-control systems learned this too — a plain force-push can destroy others' work, so the safer variant refuses to force past a change it didn't expect. Same spirit: make the common force safe and scoped, and make the dangerous force a separate, explicit choice you can't stumble into. An override should redo work, not remove guardrails.

Code

What --force touches, and what it deliberately doesn't·text

recall-archive start --source rekindled-ash --all --force

  REGENERATES (cheap, usually the intent):
    - fresh execution identity (new batch + jobs)
    - summary
    - title

  PRESERVES (the money guard, untouched):
    - paid-call identity = hash(chunk) + hash(config)
      -> identical audio still hits the completed ledger row
      -> stored response reused, NO new paid POST

  A real paid rerun is NOT reachable here. It needs either:
    - a genuine config change (new paid identity), or
    - an explicit  --allow-paid-rerun  authorization

# title-only force: re-runs the title prompt on the existing
# summary. Reads no video, prepares no audio, spends nothing.

Exercise

Find a 'force', 'overwrite', or 'redo' option in a tool you use or maintain. Ask exactly what it invalidates: does it scope to the thing you usually want redone, or does it blow away everything — including expensive or irreversible actions? If a single flag both regenerates cheap outputs and re-triggers a costly or destructive one, redesign it: scope the common force, and move the dangerous behavior behind a separate, explicit opt-in.

Hint

The test question is 'what is the worst thing this force can do, and how easy is it to trigger by reflex?' If the reflexive force can spend money or destroy data, the design is wrong. Split it: a safe, scoped force for the everyday case, and a loud, separate authorization for the irreversible one — so the dangerous path can only be chosen on purpose.