Michael Chihlas
8fd2c1bac6
All checks were successful
Mirror to GitHub / mirror (push) Successful in 11s
Wires the preview popover's Confirm & post action to ConnectWise (and,
via the provider pattern, any future PSA). Adds the parallel Escalate
flow with the handoff-oriented five-section markdown. Sessions without a
linked PSA ticket resolve/escalate locally — markdown stored, status
flipped, nothing posted externally.
Backend:
- EscalationPackageGeneratorService: Sonnet, five sections (Problem /
What we've confirmed / What we've tried / Current hypothesis /
Suggested next steps). Shares the preview_cache with a separate KIND
so Resolve and Escalate previews for the same state coexist.
- PSAWritebackService: post_resolution_note (RESOLUTION note type,
customer-visible), post_escalation_package (INTERNAL_ANALYSIS,
handoff for the next engineer only), transition_ticket_status with
mandatory re-fetch verification. PSAStatusVerificationError surfaces
loudly when CW silently rejects a status change — the
ConnectWise anti-pattern CLAUDE.md flags.
- Endpoints:
* POST /ai-sessions/{id}/escalation-package/preview
* POST /ai-sessions/{id}/resolution-note/post
* POST /ai-sessions/{id}/escalation-package/post
Outcomes: "resolved" / "escalated" with external_id + verified status,
"resolved_local" / "escalated_local" when no PSA linked.
- Target CW status IDs live in account_settings.preferences
(cw_resolved_status_id, cw_escalated_status_id). When unset, the post
proceeds without a status transition — response includes a
status_transition_skipped_reason rather than silently erroring.
- 7 tests: local-only path, PSA happy path with verified transition,
status verification failure → 502, skipped transition when
unconfigured, 409 on already-resolved re-post, escalate parallel path,
internal-analysis note type enforced.
Frontend:
- ResolutionNotePreview now kind-parameterized ('resolve' | 'escalate')
with inline edit + Confirm & post. Preview loads from the matching
backend endpoint; posting calls the matching endpoint; outcome toast
surfaces the verified CW status or the local-only result.
- AssistantChatPage: previewKind state replaces previewOpen; two toggle
buttons (Preview Resolve note / Escalate instead) in the lane's bottom
slot. handleConfirmPost dispatches by kind.
Verified 2026-04-22:
- Local-only Resolve + Escalate round-trip against the dev stack.
- Live Sonnet escalation-package preview; cache hit on repeat call
with no state change (separate cache kind from resolution-note).
- PSA post + status-verification paths covered by mocked-provider pytest
cases. Live CW round-trip pending a test CW instance.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Troubleshooting Decision Tree - Backend API
FastAPI backend for the Troubleshooting Decision Tree application.
Quick Start
1. Set up Python environment
cd backend
python -m venv venv
# Windows
venv\Scripts\activate
# macOS/Linux
source venv/bin/activate
pip install -r requirements.txt
2. Start PostgreSQL database
Using Docker:
docker-compose up -d
Or install PostgreSQL locally and create a database:
CREATE DATABASE decision_tree;
3. Configure environment
Copy the example env file and update as needed:
cp .env.example .env
4. Run database migrations
alembic upgrade head
5. Start the server
uvicorn app.main:app --reload --host 0.0.0.0 --port 8000
The API will be available at:
- API: http://localhost:8000
- Docs: http://localhost:8000/api/docs
- ReDoc: http://localhost:8000/api/redoc
API Endpoints
Authentication
POST /api/v1/auth/register- Register new userPOST /api/v1/auth/login- Login (form data)POST /api/v1/auth/login/json- Login (JSON body)POST /api/v1/auth/refresh- Refresh tokenGET /api/v1/auth/me- Get current userPOST /api/v1/auth/logout- Logout
Trees
GET /api/v1/trees- List all treesGET /api/v1/trees/categories- List categoriesGET /api/v1/trees/search?q=query- Search treesGET /api/v1/trees/{id}- Get specific treePOST /api/v1/trees- Create tree (engineer/admin)PUT /api/v1/trees/{id}- Update tree (engineer/admin)DELETE /api/v1/trees/{id}- Delete tree (admin)
Sessions
GET /api/v1/sessions- List user's sessionsGET /api/v1/sessions/{id}- Get specific sessionPOST /api/v1/sessions- Start new sessionPUT /api/v1/sessions/{id}- Update sessionPOST /api/v1/sessions/{id}/complete- Complete sessionPOST /api/v1/sessions/{id}/export- Export session
Development
Create new migration
alembic revision --autogenerate -m "description"
Run migrations
alembic upgrade head
Rollback migration
alembic downgrade -1
Project Structure
backend/
├── alembic/ # Database migrations
│ └── versions/
├── app/
│ ├── api/
│ │ ├── endpoints/ # API route handlers
│ │ ├── deps.py # Dependencies (auth, etc.)
│ │ └── router.py # Main router
│ ├── core/
│ │ ├── config.py # Settings
│ │ ├── database.py # DB connection
│ │ └── security.py # JWT, password hashing
│ ├── models/ # SQLAlchemy models
│ ├── schemas/ # Pydantic schemas
│ └── main.py # FastAPI app
├── tests/
├── alembic.ini
├── docker-compose.yml
├── requirements.txt
└── README.md