zzstoatzz.io
+11
-11
.github/workflows/status-maintenance.yml
+11
-11
.github/workflows/status-maintenance.yml
···
52
53
## critical rules
54
55
-
1. STATUS.md MUST be kept under 250 lines. this is non-negotiable.
56
2. archive content MUST be moved to .status_history/, not deleted
57
3. podcast tone MUST be dry, matter-of-fact, slightly sardonic - NOT enthusiastic or complimentary
58
···
75
76
## task 2: archive old sections (MANDATORY if over 250 lines)
77
78
-
if STATUS.md > 250 lines:
79
1. create .status_history/ directory if it doesn't exist
80
2. identify section boundaries (look for "---" separators and "### " headers with dates)
81
3. move OLDEST sections to .status_history/YYYY-MM.md (grouped by month)
82
-
4. keep ONLY the most recent content totaling ~200-250 lines in STATUS.md
83
-
5. preserve the document structure (keep "## recent work" header, "## immediate priorities", etc)
84
-
6. do NOT summarize archived content - move it verbatim
85
86
-
example (which happens to be from November 2025): if STATUS.md has sections from Nov 10, Nov 12, Nov 24, Nov 27, Dec 1:
87
-
- move Nov 10-24 content to .status_history/2025-11.md
88
-
- keep Nov 27 and Dec 1 content in STATUS.md
89
90
-
VERIFY: run `wc -l STATUS.md` after archiving. it MUST be under 250 lines.
91
92
## task 3: generate audio overview (if skip_audio is false)
93
···
116
117
write to podcast_script.txt with "Host: ..." and "Cohost: ..." lines.
118
119
-
INAUGURAL EPISODE (first time):
120
- introduce what plyr.fm is: decentralized music streaming on ATProto
121
- explain the core value prop: your music data lives in your PDS, portable between apps (open social)
122
- cover the technical foundation that's been built (summarize from STATUS.md)
···
124
- tone: "here's what is being built and why it could matter"
125
- work chronologically from beginning to end, don't heavily bias towards nascent or recent work
126
127
-
SUBSEQUENT EPISODES:
128
- focus on what actually shipped since last episode
129
- use git history to determine timing ("last week" vs "earlier this month")
130
- don't re-explain the whole project - listeners already know
···
52
53
## critical rules
54
55
+
1. STATUS.md MUST be kept under 500 lines. this is non-negotiable.
56
2. archive content MUST be moved to .status_history/, not deleted
57
3. podcast tone MUST be dry, matter-of-fact, slightly sardonic - NOT enthusiastic or complimentary
58
···
75
76
## task 2: archive old sections (MANDATORY if over 250 lines)
77
78
+
if STATUS.md > 500 lines:
79
1. create .status_history/ directory if it doesn't exist
80
2. identify section boundaries (look for "---" separators and "### " headers with dates)
81
3. move OLDEST sections to .status_history/YYYY-MM.md (grouped by month)
82
+
4. compact the meaning of the original entire STATUS.md into about 500 lines or less
83
+
5. generally preserve the document structure (keep "## recent work" header, "## immediate priorities", etc)
84
+
6. do NOT summarize archived content - move it verbatim and organize it chronologically
85
86
+
so STATUS.md is the living overview, slightly recency biased, but a good general overview of the project.
87
+
88
+
.status_history/ is the archive of temporally specific sections of STATUS.md that are worth preserving for historical context, but not significant enought to be stated literally in STATUS.md in perpetuity.
89
90
+
VERIFY: run `wc -l STATUS.md` after archiving. it MUST be under 500 lines.
91
92
## task 3: generate audio overview (if skip_audio is false)
93
···
116
117
write to podcast_script.txt with "Host: ..." and "Cohost: ..." lines.
118
119
+
INAUGURAL EPISODE (ignore this if its not the first episode):
120
- introduce what plyr.fm is: decentralized music streaming on ATProto
121
- explain the core value prop: your music data lives in your PDS, portable between apps (open social)
122
- cover the technical foundation that's been built (summarize from STATUS.md)
···
124
- tone: "here's what is being built and why it could matter"
125
- work chronologically from beginning to end, don't heavily bias towards nascent or recent work
126
127
+
SUBSEQUENT EPISODES (ignore this if its the first episode):
128
- focus on what actually shipped since last episode
129
- use git history to determine timing ("last week" vs "earlier this month")
130
- don't re-explain the whole project - listeners already know