Unify the Project Revival Story

Work directly in:

/home/kernel-kain/Documents/Github/unfinished-business

Execution rules:

1. Work only on the main branch.
2. Begin with:
   • git status
   • git switch main
   • git pull --ff-only origin main
3. Preserve all unrelated changes, untracked files, and existing stashes. Do not apply, delete, or commit .backboard/, .unfinished-business/, .env files, credentials, or the existing stash unless this phase explicitly requires it.
4. Read the relevant source, tests, AGENTS.md files, and documentation before editing.
5. Implement only the phase described below. Do not begin the next phase.
6. Maintain backward compatibility with existing saved projects through explicit migrations.
7. Do not expose provider secrets, prompts containing secrets, or private model output in logs, telemetry, screenshots, or error messages.
8. Add or update tests for every behavior changed.
9. After implementation, update the relevant project documentation, including:
   • README.md when user-facing behavior changes
   • docs/ARCHITECTURE.md
   • docs/DECISIONS.md
   • docs/IMPLEMENTATION_PLAN.md
   • docs/EVIDENCE.md
   • docs/RELEASE_NOTES.md
   • any phase-specific setup or integration documentation
10. Mark the phase complete in the implementation plan only after its acceptance criteria pass.
11. Run all relevant verification. At minimum:

• npm run typecheck
• npm test
• npm run build Run visual, security, budget, contract, migration, or integration tests when affected.

1. Review the final git diff for accidental files, secrets, debugging output, and unrelated changes.
2. Commit with the commit message specified by this phase.
3. Push the commit to origin/main. Never force-push.
4. If the push is rejected because origin/main advanced, fetch and rebase safely, resolve only scoped conflicts, rerun verification, and push normally.
5. Finish with:

• implementation summary
• changed files
• documentation updated
• tests and results
• known limitations
• commit hash
• push result

Do not stop for ordinary implementation decisions. Stop only if there is a destructive conflict, missing required credential, irreconcilable remote conflict, or a decision that would materially change the product’s intended behavior.

Implement Phase 6: replace the inconsistent demo, rewrite the landing page, and make the hackathon theme part of the product story.

Objectives:

• Use one canonical sample dataset.
• Replace the generic example with a coherent abandoned-project revival.
• Simplify landing-page copy and visual hierarchy.
• Make the OpenCode relationship understandable.

Implementation requirements:

1. Create one canonical demo fixture used by:
   • guided demo;
   • landing preview;
   • visual tests;
   • screenshots;
   • evidence examples.
2. Remove contradictory PASS/FAIL states from separate fixture sources.
3. Replace the current example with a small, self-contained abandoned open-source project:
   • clear original problem;
   • Oracle discovery;
   • Architect plan;
   • bounded Maker change;
   • relevant test;
   • honest Witness evidence.
4. Make every section and generated artifact consistent with the same example.
5. Rewrite technical/jargon-heavy demo text in plain language.
6. Keep technical fixture disclosures available, but place them under details.
7. Rebuild the landing page around:
   • Hero
   • Four-stage workflow
   • Sample project
   • Why OpenCode
   • Local setup and privacy
   • FAQ/final CTA
8. Keep Try the example as the primary CTA.
9. Remove the duplicate Watch guided flow action.
10. Keep Run locally as a secondary action.
11. Replace technical hero facts with user outcomes:
    • Clarify the idea
    • Approve the plan
    • Build with OpenCode
    • Verify the result
12. Rewrite “OpenCode is the engine” in direct language.
13. Rename or replace:
    • Deterministic walkthrough
    • OpenCode controls and evidence
    • Hosted demo or private hosted
    • Full local mode
14. Remove the idea-to-tool recommendation unless it becomes genuinely interactive and capability-driven.
15. Replace the generic hero image with a bespoke visual aligned with the four spirits and abandoned-project workshop concept. If creating a raster illustration, use the available image-generation skill and store an optimized web asset with appropriate responsive variants.
16. Reduce oversized typography, excess glass cards, pills, outlines, glows, and monospace labels.
17. Add fixture-consistency and visual-regression tests.

Acceptance criteria:

• Landing and demo always report the same sample outcome.
• The sample tells one coherent story from idea through evidence.
• The hackathon theme is functional rather than cosmetic.
• The page has one obvious primary CTA.
• Desktop and mobile layouts have intentional scale and spacing.

Commit message:

feat(demo): unify the project revival story