/salvage

• Work is drifting - approach has changed direction multiple times
• Approach reversed 3+ times - you're oscillating, not converging
• Scope expanding while "done" keeps fuzzing - the finish line keeps moving
• You're protecting code you've invested in - afraid to throw it away
• Starting over feels right - but you don't want to lose what you learned

"This session/approach is being salvaged because [reason]. The original aim was [aim]. What actually happened was [reality]."

• What assumptions were wrong?
• What did you learn about the problem that you didn't know before?
• What would you tell yourself at the start of this work?

"I thought X, but actually Y."

• What boundaries should have been explicit from the start?
• What "don't do this" rules emerged?
• What edge cases bit you?

Guardrail: [boundary]
Reason: [why this matters]
Trigger: [when to revisit this constraint]

• What questions should have been asked at the start?
• What existing code/patterns should have been found first?
• What documentation was missing or would have prevented this?

"If I had known about [X], I would have [Y] instead."

• What tribal knowledge did this work surface?
• What would help future-you (or future teammates) in similar situations?
• What patterns should be captured?

• Specific enough to be actionable
• General enough to apply beyond this exact case
• Non-obvious (not "write tests" but "this API silently returns 200 on auth failure")

• What approaches or code fragments are worth keeping?
• What partial solutions could seed the restart?
• What tools or techniques proved useful?

1. [Learning 1]
2. [Learning 2]
3. [Learning 3]

• [Guardrail 1]
• [Guardrail 2]

1. Log to OH - Log tribal knowledge and guardrails to the graph
2. Update AGENTS.md - If learnings are project-wide, suggest additions

1. The complexity isn't in the auth code—it's in the 6 different OAuth providers
2. Each provider has subtly different token refresh behavior
3. The "simple" unified flow breaks provider-specific error handling

• Guardrail: Don't abstract OAuth providers into single interface
• Reason: Provider differences are semantic, not syntactic
• Trigger: Revisit if we drop to 2 providers or less

• The original auth was complex for a reason (provider edge cases)
• Should have read the PR that introduced each provider

1. No theme system exists—colors are hardcoded across components
2. A toggle without infrastructure is meaningless
3. This is actually two tasks: (1) build theme system, (2) add toggle

• Guardrail: UI feature requests need infrastructure check first
• Reason: "Add X" often implies "build system for X"
• Trigger: Any request that touches visual consistency

• Should have grepped for color usage before starting
• No design tokens or CSS variables in codebase

• Color mapping I started: styles/colors.js (incomplete but useful)
• Component audit list: 14 files that hardcode colors

1. First: Create theme system (CSS variables, ThemeContext)
2. Then: Add dark mode as first theme variant
3. The toggle is the easy part—do it last

undefined

.oh/<session>.md

/salvage auth-refactor

• Reads/writes

  .oh/auth-refactor.md

  directly

/salvage

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

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

• Suggest a name based on git branch or the work being salvaged

undefined

• Reads

  .oh/<session>.md

  for full session context
• Writes salvage report to the session file
• The salvage report can seed the next session

• Queries related past decisions before salvaging
• Logs learnings to graph database
• Creates dive pack for restart session
• Session file serves as local cache

• /aim

  - Reclarify what we're actually trying to achieve

• /problem-space

  - Fresh start with new understanding
• Create new task/issue with salvage context attached