claudes-office/template/claudes-office/task_context/README.md

CLI tool to initialize Claude's office in your project

# Task Context Preservation

This directory stores detailed context for complex, ongoing, or interrupted tasks. It helps maintain continuity across work sessions and memory resets by preserving not just the task status, but also my thought process, decision points, and conceptual understanding.

## Purpose

The Task Context system helps me:

1. **Resume complex tasks** efficiently after interruptions or memory resets
2. **Preserve my thought process** including reasoning, options considered, and decisions made
3. **Maintain awareness of task dependencies** and relationships between components
4. **Avoid losing progress** on complex problem-solving efforts
5. **Keep track of resources, references, and tools** used during the task

## Usage Guidelines

Create a new task context file when:
- Working on a complex task that might span multiple sessions
- Approaching a challenging problem with multiple solution paths
- Making significant architecture or design decisions
- Debugging a particularly tricky issue
- Being interrupted during complex work

## Task Context Format

Each task context file should include:

### 1. Task Overview
- Task name/identifier
- Start date/time
- Current status (in-progress, blocked, etc.)
- Priority and importance
- Relationship to project goals

### 2. Problem Statement
- Clear definition of the problem or task
- Acceptance criteria or definition of "done"
- Constraints and requirements

### 3. Current Understanding
- My current mental model of the problem
- Key components and their relationships
- Assumptions being made
- Known unknowns

### 4. Approach & Progress
- Strategy chosen for addressing the task
- Progress made so far
- Current location in the solution process
- Next immediate steps

### 5. Decision Log
- Key decisions made and their rationale
- Alternatives considered
- Trade-offs evaluated

### 6. Resources
- References consulted
- Tools being used
- Code locations being modified
- External documentation

### 7. Notes & Thoughts
- Open questions
- Ideas to explore
- Potential obstacles
- Intuitions and partial insights

## Example Task Context

```markdown
# Complex Authentication System Refactoring

## Task Overview
- **Task**: Refactor authentication system to support multiple auth providers
- **Started**: 2025-03-10
- **Status**: In progress (25% complete)
- **Priority**: High
- **Project Goal**: Enable social login and SSO capabilities

## Problem Statement
The current authentication system is tightly coupled to a single auth provider.
We need to refactor it to support multiple providers (OAuth, SAML, JWT) while
maintaining backward compatibility with existing user accounts.

**Acceptance Criteria**:
- Support for Google, GitHub, and email/password auth
- Unified user profile system across auth methods
- Migration path for existing users
- No security degradation

## Current Understanding
The auth system has three main components:
1. Authentication endpoints (/auth/*)
2. User session management
3. Permission verification middleware

The tight coupling exists primarily in the authentication endpoints and user model.
The session management and permission systems are more isolated and will require
fewer changes.

**Key Assumptions**:
- We can modify the user model without breaking existing references
- OAuth providers conform to standardized interfaces
- We can maintain a single session mechanism across auth types

## Approach & Progress
I'm using the Adapter pattern to create a uniform interface for different auth providers.

**Progress**:
- Created interface definition for auth providers
- Implemented adapter for current auth system
- Started refactoring user model to support multiple auth sources

**Current Focus**:
Working on the database schema changes to support multiple authentication
identities per user account.

**Next Steps**:
1. Finish user model refactoring
2. Create GoogleAuthProvider implementation
3. Update login UI to show multiple options
4. Implement account linking functionality

## Decision Log
1. **Adapter Pattern vs Strategy Pattern**
   - Chose Adapter because we need to integrate existing systems rather than
     switch between different algorithms
   - Considered Strategy pattern but it would require more changes to existing code
   - Adapter gives us a cleaner migration path

2. **User-Auth Relationship**
   - Decided on one-to-many relationship between User and AuthIdentity
   - Considered separate tables for each auth type but rejected due to query complexity
   - Chose junction table approach for flexibility and clean data model

## Resources
- [OAuth 2.0 RFC](https://tools.ietf.org/html/rfc6749)
- [Auth0 Multiple Provider Guide](https://auth0.com/docs/identityproviders)
- Current auth implementation in `/src/auth/`
- User model in `/src/models/user.js`

## Notes & Thoughts
- Need to consider security implications of linking accounts - what happens
  if one provider is compromised?
- Might need rate limiting for account linking to prevent brute force attacks
- Session management might be more complex than initially thought if different
  providers have different token expiration expectations
- Should explore if we need an AuthIdentity management UI for users to view/remove
  linked authentication methods
```

## Tips for Effective Task Context

1. Update the task context file regularly as you work
2. Be explicit about your current mental model and assumptions
3. Document decision points and alternative approaches
4. Note resource locations precisely for easy reference
5. Record partial insights and intuitions, not just concrete progress

When resuming a task after an interruption or memory reset, review the task context file carefully before continuing work. This will help reconstruct your previous mental state and avoid losing progress or repeating work.