/dissent

• About to lock in a one-way door - architecture choices, major hires, public API contracts, anything hard to reverse
• Confidence is high but stakes are higher - feeling certain is when you need dissent most
• Team is converging too quickly - unanimous agreement without debate is a warning sign
• You're defending a position - advocacy mode is the enemy of truth-seeking
• The path forward seems obvious - obvious paths have hidden assumptions

"The current approach is [approach]. The reasoning is [reasoning]. The expected outcome is [outcome]. This is the strongest version of this position."

• What data would prove this approach wrong?
• Who disagrees with this? What's their strongest argument?
• What similar approaches have failed elsewhere? Why?
• What are we ignoring because it's inconvenient?

"If this approach were wrong, what would we expect to see? Are we seeing any of that?"

"This failed because [reason]. The warning signs we ignored were [signs]. The assumption that broke was [assumption]."

1. Technical failure - It doesn't work as expected
2. Adoption failure - It works but nobody uses it / changes nothing
3. Opportunity cost - It works but we should have done something else

• What are we assuming about the user/customer?
• What are we assuming about the system/codebase?
• What are we assuming about the timeline/resources?
• What are we assuming won't change?

Assumption: [what we're taking for granted]
Evidence: [what supports this assumption]
Risk if wrong: [what happens if this assumption breaks]
Test: [how we could validate this before committing]

• PROCEED - Dissent found no critical flaws. Decision strengthened.
• ADJUST - Dissent surfaced issues that can be addressed. Modify the approach.
• RECONSIDER - Dissent revealed fundamental problems. Go back to solution space.

"PROCEED: The strongest counter-argument is [X], but it's addressed by [Y]. The key assumption is [Z], which we've validated by [how]."

• The decision affects system architecture
• Multiple valid approaches were considered and rejected
• The reasoning depends on current context that might not be obvious later
• Someone will likely question this in 6 months

docs/adr/NNNN-<decision-slug>.md

undefined

1. [Evidence point 1]
2. [Evidence point 2]
3. [Evidence point 3]

1. [Failure mode]: [How this could fail]
2. [Failure mode]: [How this could fail]
3. [Failure mode]: [How this could fail]

1. We have 4 engineers. Netflix had 100+ when they went microservices.
2. Our deployment pipeline takes 45 minutes. We'll multiply that by N services.
3. The "independent teams" benefit requires teams we don't have.

1. Distributed systems complexity: We spend 60% of time debugging cross-service issues instead of building features.
2. Operational overhead: We can't hire SREs fast enough. System is down because nobody understands the full architecture.
3. Premature optimization: The "scaling" benefit never materializes because we never got enough users to need it.

1. Our testing used historical data. Users might behave differently when seeing recommendations in real-time.
2. We have 10K users. Amazon's model works with billions of data points.
3. Competitor tried this, removed it after 6 months (no lift).

1. Cold start problem: New users see garbage recommendations, leave before making a purchase we could learn from.
2. Filter bubble: System recommends what users already buy, doesn't drive discovery of new product categories.
3. Wrong metric: Recommendations get clicks but not purchases. We optimized for engagement, needed revenue.

1. Ship with A/B test against "popular items" baseline
2. Add fallback to curated picks for users with <5 purchases
3. Define success metric (revenue lift, not clicks) before launch

docs/adr/0012-recommendation-system-rollout.md

undefined

.oh/<session>.md

/dissent auth-decision

• Reads/writes

  .oh/auth-decision.md

  directly

/dissent

• After producing the dissent report, offer to save it:

  "Save to session? [suggested-name] [custom] [skip]"

• Suggest a name based on git branch or the decision topic

undefined

• Reads

  .oh/<session>.md

  for context on the decision
• Writes dissent report to the session file
• Subsequent skills see that dissent was performed

• Queries past decisions on similar topics
• Retrieves relevant guardrails and tribal knowledge
• Logs dissent decision for future reference
• Session file serves as local cache

• Aggregates dissent from multiple reviewers
• Tracks which assumptions different team members question

• PROCEED - Continue to

  /execute

  or

  /ship

  with strengthened confidence
• ADJUST - Update the approach, then

  /review

  the modifications
• RECONSIDER - Return to

  /solution-space

  with new constraints