test — Motivations

Why this project exists

1. Validate the Rails bot end-to-end. Before rolling it out to real projects, we need to confirm the core workflow actually works — creating projects, moving through stages, tracking context, and keeping everything in sync via git.

2. Catch bugs early. Find and fix issues now so we don't waste Dan's time (or anyone else's) debugging during real project work.

3. Help us finish projects faster. The ultimate goal of Rails is to give the Readwise team a lightweight, always-on project manager that keeps work moving through Backlog → Shape → Build → Expedite → Ship → Learn → Done. If this test project proves the system works, we can confidently adopt it company-wide.

test — Shape

Definition of done

This project is done when @tristan feels confident that the basic technical side of the Rails bot works reliably.

Scope

The work is simply running this project through every stage — Backlog → Shape → Build → Expedite → Ship → Learn → Done — and confirming the bot handles each transition correctly.

Appetite

Small. This is a quick validation pass, not a deep build-out.

test — Build

What was done

• Ran the project through Backlog → Shape → Build to validate core bot workflows
• Tested: project creation, owner assignment, stage transitions, doc linking, status queries
• Made several bot improvements during execution:
  • Git identity auto-config (rails@readwise.io)
  • Auto-push after every commit
  • Commit links in every Slack confirmation
  • motivation.md as a new standard project doc
  • Owner emphasis in all stage transitions, assignments, and status messages
• Updated context.md with running summary of progress

test — Ship

What shipped

The Rails bot is now functional with a solid baseline feature set:

• Project creation, owner assignment, stage transitions all working
• Git-backed state management (state.yml, context.md, stage deliverables)
• Auto-push to GitHub on every commit
• Commit links in every Slack confirmation
• Owner prominently called out in transitions, assignments, and status
• Stage deliverables written automatically before each transition
• motivation.md added as a standard project doc

What's left

Ready for real-world use. Next step is to run a retro and decide if we're confident enough to bring Dan in.

test — Learn

Process: What worked

• Slack-native workflow feels natural. Talking to the bot in-channel to create projects, assign owners, and move stages worked smoothly — no context-switching to a separate tool.
• Git as the source of truth is solid. State files, context docs, and deliverables all versioned and auditable. Commit links in Slack messages make it easy to verify what changed.
• Stage deliverables capture useful context. Automatically writing shape.md, build.md, etc. before each transition creates a paper trail without extra effort.
• Auto-push keeps everything in sync. No risk of local-only commits getting lost.

Process: What didn't

• Skipped Expedite stage. The test project jumped from Build straight to Ship — the Expedite stage wasn't exercised, so that workflow is still unvalidated.
• No multi-person handoff tested. Owner was @tristan throughout. Real projects will involve ownership transfers, which weren't stress-tested here.
• Channel-to-project mapping untested at scale. Only one channel, one project. Need to see how it holds up with multiple concurrent projects.

Impact

The goal was to validate that the Rails bot works technically before involving Dan. That goal was met:

• Core workflows (create, assign, transition, status, doc linking) all function correctly
• Several improvements were made along the way (git identity, commit links, owner emphasis, motivation.md)
• Confidence level is high enough to proceed with real projects