Reality Fork 分岐現界

Delay and harden

The current repo is still too weak on clarity and distribution for a broad public push. Shipping now would create more confusion than pull.

kamiyo-protocol$HOME/Projects/kamiyo/.worktrees/kamiyo-protocol-rf-crates-publish/crates/kamiyo-reality-fork-cli2026-04-03T21:32:11.217Zreadiness 5%

Readiness

5%

Prompt

Should we ship this now?

Winner score

95%

Scoreboard

Immediacy

6%

First value is still buried behind setup, explanation, or external dependencies.

Clarity

0%

The public story is still diffuse enough that strangers will ask what the product actually does.

Proof

15%

The repo does not yet provide enough proof that the product changes real decisions.

Distribution

0%

Distribution friction is still high enough to block curiosity before the product can impress anyone.

Shareability

0%

There is still too little output a builder would want to show another human.

Trust

10%

A public launch would force builders to trust the product more than the repo currently earns.

Branches compared

Proof-first

Delay and harden

winner

Hold the broad public launch until the product has stronger external proof, packaging, and trust signals.

Details

Advantages

  • You avoid burning audience attention on a message that still needs another pass.
  • You buy time to turn strong internals into undeniable public proof.

Risks

  • Momentum cools off if the hardening phase drifts without a deadline.
  • The team may hide behind polish work instead of confronting the product wedge.

Next moves

  • Rewrite the README and launch copy around one user outcome, not the full command inventory.
  • Pick one primary install path and demote extra runtime friction to the background.
  • Set a brutal ship gate: if a builder is not impressed in three minutes, the launch is still early.

No launch

Park the product

93%

Stop spending launch calories until the wedge is sharper and the product earns attention on first contact.

Details

Advantages

  • You avoid a weak public story calcifying around the project.
  • The team can extract the strongest primitives without pretending they are already a product.

Risks

  • You lose external learning entirely for this cycle.
  • The product can become a permanent internal tool if there is no return date.

Next moves

  • Freeze launch work and write down the one future use case worth reviving.
  • Keep only the primitives that support that wedge.
  • Reopen launch planning only when the first-run artifact is strong enough to post without apology.

Flagship launch

Launch one impossible-to-miss workflow

25%

Make one repo-native workflow the product, and demote everything else to supporting machinery.

Details

Advantages

  • Core strength is already 10% across immediacy, proof, and trust.
  • You can force the public story to match the strongest technical surface.
  • The HTML, Markdown, and JSON artifact path becomes the thing people remember and share.

Risks

  • You have to cut or hide commands that do not reinforce the flagship path.
  • Breadth will look smaller at launch, even if the product is stronger.

Next moves

  • Make `reality-fork run launch --repo .` the front door for kamiyo-protocol.
  • Move secondary commands below the flagship workflow in docs and posts.
  • Rewrite the README and launch copy around one user outcome, not the full command inventory.

Broad launch

Launch the current product now

5%

Launch the full current surface now and learn in public without another major packaging pass.

Details

Advantages

  • Immediacy is already at 6%.
  • Trust and proof together average 12%.
  • You get real external signal immediately instead of optimizing in a vacuum.

Risks

  • The weakest go-to-market axis is still only 0%.
  • You will spend launch energy explaining the product instead of showing one impossible-to-miss use case.

Next moves

  • Lead with the generated report artifact, not the command list.
  • Record one repo-to-report walkthrough before the announcement thread.
  • Treat the first five external runs as message refinement, not validation theater.

Evidence

risk · Shareability · inference

The repo still lacks enough instantly shareable proof objects.

There are not yet enough visible report, screenshot, or public artifact cues in the repo surface.

risk · Clarity · inference

The public story still reads weaker than the underlying engineering.

The docs expose commands and features, but the breakout user outcome is still not obvious enough.

risk · Proof · inference

The repo still needs more public proof that the product changes decisions.

Tests alone do not create external demand; case studies and concrete caught-failures are still missing.

risk · Trust

The repo is not launch-clean right now.

10 changed files were detected in git status.

git:status

Next moves

Rewrite the README and launch copy around one user outcome, not the full command inventory.
Pick one primary install path and demote extra runtime friction to the background.
Emit HTML, Markdown, and JSON artifacts by default and give people a screenshot-worthy report.
Make one zero-config flow the public front door. If it needs a backend, ship a local mode or a public demo endpoint.

Ready posts

Announcement

Reality Fork launch verdict for kamiyo-protocol: Delay and harden. The current repo is still too weak on clarity and distribution for a broad public push. Shipping now would create more confusion than pull. Top signals: Proof 15% | Trust 10%.

Thread

1. Reality Fork scored kamiyo-protocol at 5% launch readiness. Verdict: Delay and harden.

2. Strongest signals: Proof 15% | Trust 10%. Weakest: Clarity 0% | Distribution 0%.

3. Next move: Rewrite the README and launch copy around one user outcome, not the full command inventory.

KAMIYO · Reality Fork