zzstoatzz.io
audio streaming app
plyr.fm
chore: improve status-update workflow and document auth stabilization
Updates the /status-update slash command with a structured workflow:
1. Read current STATUS.md state
2. Find undocumented work via git history
3. Understand WHY changes were made (not just what)
4. Write contextual documentation for future readers
Documents recent auth stabilization work (PRs #734-736):
- Session expiry now respects refresh token lifetime
- Queue component uses shared auth state (SSR boundary fix)
- BytesIO accepted in R2Storage.save() (playlist cover fix)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
+65
-22
.claude/commands/status-update.md
+65
-22
.claude/commands/status-update.md
···
1
1
# status update
2
2
3
-
update STATUS.md after completing significant work.
3
+
update STATUS.md to reflect recent work.
4
4
5
-
## when to update
5
+
## workflow
6
+
7
+
### 1. understand current state
6
8
7
-
after shipping something notable:
8
-
- new features or endpoints
9
-
- bug fixes worth documenting
10
-
- architectural changes
11
-
- deployment/infrastructure changes
12
-
- incidents and their resolutions
9
+
read STATUS.md to understand:
10
+
- what's already documented in `## recent work`
11
+
- the last update date (noted at the bottom)
12
+
- current priorities and known issues
13
+
14
+
### 2. find undocumented work
15
+
16
+
```bash
17
+
# find the last STATUS.md update
18
+
git log --oneline -1 -- STATUS.md
19
+
20
+
# get all commits since then
21
+
git log --oneline <last-status-commit>..HEAD
22
+
```
23
+
24
+
for each significant commit or PR:
25
+
- read the commit message and changed files
26
+
- understand WHY the change was made, not just what changed
27
+
- note architectural decisions, trade-offs, or lessons learned
28
+
29
+
### 3. decide what to document
30
+
31
+
not everything needs documentation. focus on:
32
+
- **features**: new capabilities users or developers can use
33
+
- **fixes**: bugs that affected users, especially if they might recur
34
+
- **architecture**: changes to how systems connect or data flows
35
+
- **decisions**: trade-offs made and why (future readers need context)
36
+
- **incidents**: what broke, why, and how it was resolved
37
+
38
+
skip:
39
+
- routine maintenance (dependency bumps, typo fixes)
40
+
- work-in-progress that didn't ship
41
+
- changes already well-documented in the PR
42
+
43
+
### 4. write the update
44
+
45
+
add a new subsection under `## recent work` following existing patterns:
13
46
14
-
**tip**: after running `/deploy`, consider running `/status-update` to document what shipped.
47
+
```markdown
48
+
#### brief title (PRs #NNN, date)
15
49
16
-
## how to update
50
+
**why**: the problem or motivation (1-2 sentences)
17
51
18
-
1. add a new subsection under `## recent work` with today's date
19
-
2. describe what shipped, why it matters, and any relevant PR numbers
20
-
3. update `## immediate priorities` if priorities changed
21
-
4. update `## technical state` if architecture changed
52
+
**what shipped**:
53
+
- concrete changes users or developers will notice
54
+
- link to relevant docs if applicable
22
55
23
-
## structure
56
+
**technical notes** (if architectural):
57
+
- decisions made and why
58
+
- trade-offs accepted
59
+
```
24
60
25
-
STATUS.md follows this structure:
26
-
- **long-term vision** - why the project exists
27
-
- **recent work** - chronological log of what shipped (newest first)
28
-
- **immediate priorities** - what's next
29
-
- **technical state** - architecture, what's working, known issues
61
+
### 5. update other sections if needed
30
62
31
-
old content is automatically archived to `.status_history/` - you don't need to manage this.
63
+
- `## priorities` - if focus has shifted
64
+
- `## known issues` - if bugs were fixed or discovered
65
+
- `## technical state` - if architecture changed
32
66
33
67
## tone
34
68
35
-
direct, technical, honest about limitations. useful for someone with no prior context.
69
+
write for someone with no prior context who needs to understand:
70
+
- what changed
71
+
- why it matters
72
+
- why this approach was chosen over alternatives
73
+
74
+
be direct and technical. avoid marketing language.
75
+
76
+
## after updating
77
+
78
+
commit the STATUS.md changes and open a PR for review.
+22
-1
STATUS.md
+22
-1
STATUS.md
···
79
79
80
80
---
81
81
82
+
#### auth stabilization (PRs #734-736, Jan 6-7)
83
+
84
+
**why**: multi-account support introduced edge cases where auth state could become inconsistent between frontend components, and sessions could outlive their refresh tokens.
85
+
86
+
**session expiry alignment** (PR #734):
87
+
- sessions now track refresh token lifetime and respect it during validation
88
+
- prevents sessions from appearing valid after their underlying OAuth grant expires
89
+
- dev token expiration handling aligned with same pattern
90
+
91
+
**queue auth boundary fix** (PR #735):
92
+
- queue component now uses shared layout auth state instead of localStorage session IDs
93
+
- fixes race condition where queue could attempt authenticated requests before layout resolved auth
94
+
- ensures remote queue snapshots don't inherit local update flags during hydration
95
+
96
+
**playlist cover upload fix** (PR #736):
97
+
- `R2Storage.save()` was rejecting `BytesIO` objects due to beartype's strict `BinaryIO` protocol checking
98
+
- changed type hint to `BinaryIO | BytesIO` to explicitly accept both
99
+
- found via Logfire: only 2 failures in production, both on Jan 3
100
+
101
+
---
102
+
82
103
#### artist bio links (PRs #700-701, Jan 2)
83
104
84
105
**links in artist bios now render as clickable** - supports full URLs and bare domains (e.g., "example.com"):
···
347
368
348
369
---
349
370
350
-
this is a living document. last updated 2026-01-06.
371
+
this is a living document. last updated 2026-01-07.