zzstoatzz.io
+65
-22
.claude/commands/status-update.md
+65
-22
.claude/commands/status-update.md
···
1
# status update
2
3
-
update STATUS.md after completing significant work.
4
5
-
## when to update
6
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
13
14
-
**tip**: after running `/deploy`, consider running `/status-update` to document what shipped.
15
16
-
## how to update
17
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
22
23
-
## structure
24
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
30
31
-
old content is automatically archived to `.status_history/` - you don't need to manage this.
32
33
## tone
34
35
-
direct, technical, honest about limitations. useful for someone with no prior context.
···
1
# status update
2
3
+
update STATUS.md to reflect recent work.
4
5
+
## workflow
6
+
7
+
### 1. understand current state
8
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:
46
47
+
```markdown
48
+
#### brief title (PRs #NNN, date)
49
50
+
**why**: the problem or motivation (1-2 sentences)
51
52
+
**what shipped**:
53
+
- concrete changes users or developers will notice
54
+
- link to relevant docs if applicable
55
56
+
**technical notes** (if architectural):
57
+
- decisions made and why
58
+
- trade-offs accepted
59
+
```
60
61
+
### 5. update other sections if needed
62
63
+
- `## priorities` - if focus has shifted
64
+
- `## known issues` - if bugs were fixed or discovered
65
+
- `## technical state` - if architecture changed
66
67
## tone
68
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
80
---
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
+
103
#### artist bio links (PRs #700-701, Jan 2)
104
105
**links in artist bios now render as clickable** - supports full URLs and bare domains (e.g., "example.com"):
···
368
369
---
370
371
+
this is a living document. last updated 2026-01-07.