muse-crew 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +19 -0
- package/API.md +213 -0
- package/README.md +68 -0
- package/docs/AGENTS.md +3 -0
- package/docs/guide.md +333 -0
- package/identities/AGENTS.md +7 -0
- package/identities/cass.md +36 -0
- package/identities/hazel.md +35 -0
- package/identities/mara.md +31 -0
- package/identities/personality-notes.md +81 -0
- package/identities/sage.md +31 -0
- package/identities/tate.md +35 -0
- package/identities/wren.md +36 -0
- package/lib/AGENTS.md +8 -0
- package/lib/crew-release.sh +188 -0
- package/lib/merge-lock.sh +89 -0
- package/lib/orphan-sweep.sh +95 -0
- package/lib/worktree-lifecycle.sh +313 -0
- package/package.json +29 -0
- package/personas/AGENTS.md +5 -0
- package/personas/beginner.md +24 -0
- package/personas/completionist.md +24 -0
- package/personas/designer.md +26 -0
- package/personas/financial-stakeholder.md +25 -0
- package/personas/power-user.md +26 -0
- package/seed/AGENTS.md +8 -0
- package/seed/cron-body-template.md +20 -0
- package/seed/feedback/AGENTS.md +3 -0
- package/seed/feedback/README.md +40 -0
- package/seed/posture.md +8 -0
- package/seed/workflows/AGENTS.md +3 -0
- package/seed/workflows/bugfix.md +39 -0
- package/seed/workflows/chore.md +29 -0
- package/seed/workflows/docs.md +17 -0
- package/seed/workflows/standard.md +34 -0
- package/workflows/AGENTS.md +12 -0
- package/workflows/bugfix.js +341 -0
- package/workflows/chore.js +294 -0
- package/workflows/crew-dispatch.js +315 -0
- package/workflows/crew-init.js +254 -0
- package/workflows/docs.js +141 -0
- package/workflows/standard.js +350 -0
|
@@ -0,0 +1,313 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# worktree-lifecycle.sh — git worktree lifecycle manager for Muse Crew
|
|
3
|
+
#
|
|
4
|
+
# Commands:
|
|
5
|
+
# validate <task_id> — check task ID is safe for branches/paths
|
|
6
|
+
# prepare <task_id> — create worktree + branch, register ownership
|
|
7
|
+
# inspect <task_id> — diff against main for review
|
|
8
|
+
# integrate <task_id> <commit_msg> — merge lock → merge into main → report commit
|
|
9
|
+
# post-deploy <task_id> — commit builder artifacts, cleanup, release lock
|
|
10
|
+
# cleanup <task_id> — remove worktree + branch (no lock)
|
|
11
|
+
# status <task_id> — report worktree state
|
|
12
|
+
# refresh-lock <task_id> — refresh merge lock timestamp (resets staleness clock)
|
|
13
|
+
# sweep [report|clean] — find/clean orphans + stale locks
|
|
14
|
+
#
|
|
15
|
+
# Exit codes:
|
|
16
|
+
# 0 — success
|
|
17
|
+
# 1 — validation/usage error
|
|
18
|
+
# 2 — merge lock held by another task
|
|
19
|
+
# 3 — merge conflict
|
|
20
|
+
# 4 — dirty main (cannot merge)
|
|
21
|
+
|
|
22
|
+
set -euo pipefail
|
|
23
|
+
|
|
24
|
+
REPO="${CREW_REPO:-$HOME/workspace/ts-spaces/orchestra-dashboard}"
|
|
25
|
+
WORKTREE_DIR="$REPO/.worktrees"
|
|
26
|
+
REGISTRY_DIR="$WORKTREE_DIR/.registry"
|
|
27
|
+
LIB_DIR="${CREW_LIB:-$HOME/workspace/.jarvis/lib}"
|
|
28
|
+
MERGE_LOCK="$LIB_DIR/merge-lock.sh"
|
|
29
|
+
ORPHAN_SWEEP="$LIB_DIR/orphan-sweep.sh"
|
|
30
|
+
|
|
31
|
+
# --- helpers ---
|
|
32
|
+
|
|
33
|
+
validate_task_id() {
|
|
34
|
+
local id="$1"
|
|
35
|
+
if [[ ! "$id" =~ ^[a-zA-Z0-9][a-zA-Z0-9_-]*$ ]]; then
|
|
36
|
+
echo "ERROR: invalid task_id '$id' — must match [a-zA-Z0-9][a-zA-Z0-9_-]*"
|
|
37
|
+
return 1
|
|
38
|
+
fi
|
|
39
|
+
if [ "${#id}" -gt 64 ]; then
|
|
40
|
+
echo "ERROR: task_id too long (${#id} chars, max 64)"
|
|
41
|
+
return 1
|
|
42
|
+
fi
|
|
43
|
+
return 0
|
|
44
|
+
}
|
|
45
|
+
|
|
46
|
+
require_clean_main() {
|
|
47
|
+
cd "$REPO"
|
|
48
|
+
git checkout main 2>/dev/null
|
|
49
|
+
local dirty
|
|
50
|
+
dirty=$(git status --porcelain 2>/dev/null | wc -l)
|
|
51
|
+
if [ "$dirty" -gt 0 ]; then
|
|
52
|
+
echo "ERROR: main has $dirty uncommitted changes"
|
|
53
|
+
git status --short
|
|
54
|
+
return 1
|
|
55
|
+
fi
|
|
56
|
+
return 0
|
|
57
|
+
}
|
|
58
|
+
|
|
59
|
+
register() {
|
|
60
|
+
local task_id="$1" base_commit="$2"
|
|
61
|
+
mkdir -p "$REGISTRY_DIR"
|
|
62
|
+
cat > "$REGISTRY_DIR/$task_id" <<EOF
|
|
63
|
+
task_id=$task_id
|
|
64
|
+
branch=task/$task_id
|
|
65
|
+
path=$WORKTREE_DIR/$task_id
|
|
66
|
+
base_commit=$base_commit
|
|
67
|
+
created=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
|
68
|
+
EOF
|
|
69
|
+
}
|
|
70
|
+
|
|
71
|
+
unregister() {
|
|
72
|
+
rm -f "$REGISTRY_DIR/$1"
|
|
73
|
+
}
|
|
74
|
+
|
|
75
|
+
# --- commands ---
|
|
76
|
+
|
|
77
|
+
cmd_validate() {
|
|
78
|
+
local task_id="$1"
|
|
79
|
+
validate_task_id "$task_id"
|
|
80
|
+
echo "VALID: $task_id"
|
|
81
|
+
}
|
|
82
|
+
|
|
83
|
+
cmd_prepare() {
|
|
84
|
+
local task_id="$1"
|
|
85
|
+
validate_task_id "$task_id"
|
|
86
|
+
|
|
87
|
+
cd "$REPO"
|
|
88
|
+
git worktree prune 2>/dev/null
|
|
89
|
+
|
|
90
|
+
# Reuse existing worktree
|
|
91
|
+
if [ -d "$WORKTREE_DIR/$task_id" ]; then
|
|
92
|
+
echo "REUSED: worktree exists at .worktrees/$task_id"
|
|
93
|
+
local head
|
|
94
|
+
head=$(cd "$WORKTREE_DIR/$task_id" && git rev-parse HEAD)
|
|
95
|
+
echo "HEAD: $head"
|
|
96
|
+
return 0
|
|
97
|
+
fi
|
|
98
|
+
|
|
99
|
+
# Preflight: main must be clean
|
|
100
|
+
require_clean_main || exit 4
|
|
101
|
+
|
|
102
|
+
local base_commit
|
|
103
|
+
base_commit=$(git rev-parse HEAD)
|
|
104
|
+
|
|
105
|
+
# Create branch + worktree
|
|
106
|
+
git branch -D "task/$task_id" 2>/dev/null || true
|
|
107
|
+
mkdir -p "$WORKTREE_DIR"
|
|
108
|
+
git worktree add "$WORKTREE_DIR/$task_id" -b "task/$task_id"
|
|
109
|
+
|
|
110
|
+
register "$task_id" "$base_commit"
|
|
111
|
+
|
|
112
|
+
echo "CREATED: .worktrees/$task_id on branch task/$task_id"
|
|
113
|
+
echo "BASE: $base_commit"
|
|
114
|
+
}
|
|
115
|
+
|
|
116
|
+
cmd_inspect() {
|
|
117
|
+
local task_id="$1"
|
|
118
|
+
validate_task_id "$task_id"
|
|
119
|
+
|
|
120
|
+
cd "$REPO"
|
|
121
|
+
|
|
122
|
+
# Verify the branch exists
|
|
123
|
+
if ! git rev-parse --verify "task/$task_id" >/dev/null 2>&1; then
|
|
124
|
+
echo "ERROR: branch task/$task_id does not exist"
|
|
125
|
+
return 1
|
|
126
|
+
fi
|
|
127
|
+
|
|
128
|
+
echo "=== Diff: main...task/$task_id ==="
|
|
129
|
+
git diff --stat "main...task/$task_id"
|
|
130
|
+
echo ""
|
|
131
|
+
git diff "main...task/$task_id"
|
|
132
|
+
}
|
|
133
|
+
|
|
134
|
+
cmd_integrate() {
|
|
135
|
+
local task_id="$1"
|
|
136
|
+
local commit_msg="${2:-merge: $task_id}"
|
|
137
|
+
validate_task_id "$task_id"
|
|
138
|
+
|
|
139
|
+
cd "$REPO"
|
|
140
|
+
|
|
141
|
+
# Preflight: main must be clean
|
|
142
|
+
require_clean_main || exit 4
|
|
143
|
+
|
|
144
|
+
# Verify task branch exists and has commits ahead of main
|
|
145
|
+
if ! git rev-parse --verify "task/$task_id" >/dev/null 2>&1; then
|
|
146
|
+
echo "ERROR: branch task/$task_id does not exist"
|
|
147
|
+
return 1
|
|
148
|
+
fi
|
|
149
|
+
|
|
150
|
+
local ahead
|
|
151
|
+
ahead=$(git rev-list --count "main..task/$task_id")
|
|
152
|
+
if [ "$ahead" -eq 0 ]; then
|
|
153
|
+
echo "ERROR: task/$task_id has no commits ahead of main — nothing to merge"
|
|
154
|
+
return 1
|
|
155
|
+
fi
|
|
156
|
+
|
|
157
|
+
# Acquire merge lock
|
|
158
|
+
local lock_result
|
|
159
|
+
if ! lock_result=$("$MERGE_LOCK" acquire "$task_id" "$$"); then
|
|
160
|
+
echo "LOCK_HELD: $lock_result"
|
|
161
|
+
exit 2
|
|
162
|
+
fi
|
|
163
|
+
echo "$lock_result"
|
|
164
|
+
|
|
165
|
+
# Merge
|
|
166
|
+
if ! git merge --no-ff "task/$task_id" -m "$commit_msg" 2>&1; then
|
|
167
|
+
echo "CONFLICT: merge failed — aborting"
|
|
168
|
+
git merge --abort 2>/dev/null || true
|
|
169
|
+
"$MERGE_LOCK" release "$task_id" >/dev/null 2>&1
|
|
170
|
+
exit 3
|
|
171
|
+
fi
|
|
172
|
+
|
|
173
|
+
local merged_commit
|
|
174
|
+
merged_commit=$(git rev-parse HEAD)
|
|
175
|
+
echo "MERGED: $merged_commit"
|
|
176
|
+
echo "LOCK: held by $task_id — release after deploy with post-deploy"
|
|
177
|
+
}
|
|
178
|
+
|
|
179
|
+
cmd_post_deploy() {
|
|
180
|
+
local task_id="$1"
|
|
181
|
+
validate_task_id "$task_id"
|
|
182
|
+
|
|
183
|
+
cd "$REPO"
|
|
184
|
+
git checkout main 2>/dev/null
|
|
185
|
+
|
|
186
|
+
# Commit any changes the artifact builder left behind
|
|
187
|
+
git add -A
|
|
188
|
+
if ! git diff --cached --quiet 2>/dev/null; then
|
|
189
|
+
git commit -m "rebuild: $task_id"
|
|
190
|
+
echo "COMMITTED: artifact builder changes"
|
|
191
|
+
else
|
|
192
|
+
echo "CLEAN: no artifact builder changes"
|
|
193
|
+
fi
|
|
194
|
+
|
|
195
|
+
local final_commit
|
|
196
|
+
final_commit=$(git rev-parse HEAD)
|
|
197
|
+
|
|
198
|
+
# Cleanup worktree + branch
|
|
199
|
+
if [ -d "$WORKTREE_DIR/$task_id" ]; then
|
|
200
|
+
git worktree remove "$WORKTREE_DIR/$task_id" 2>/dev/null || true
|
|
201
|
+
echo "WORKTREE: removed"
|
|
202
|
+
fi
|
|
203
|
+
git worktree prune 2>/dev/null
|
|
204
|
+
git branch -d "task/$task_id" 2>/dev/null && echo "BRANCH: deleted" || true
|
|
205
|
+
unregister "$task_id"
|
|
206
|
+
|
|
207
|
+
# Release merge lock
|
|
208
|
+
"$MERGE_LOCK" release "$task_id" 2>/dev/null && echo "LOCK: released" || true
|
|
209
|
+
|
|
210
|
+
echo "DEPLOYED: $final_commit"
|
|
211
|
+
}
|
|
212
|
+
|
|
213
|
+
cmd_cleanup() {
|
|
214
|
+
local task_id="$1"
|
|
215
|
+
validate_task_id "$task_id"
|
|
216
|
+
|
|
217
|
+
cd "$REPO"
|
|
218
|
+
|
|
219
|
+
if [ -d "$WORKTREE_DIR/$task_id" ]; then
|
|
220
|
+
# Check for dirty state
|
|
221
|
+
local dirty
|
|
222
|
+
dirty=$(cd "$WORKTREE_DIR/$task_id" && git status --porcelain 2>/dev/null | wc -l)
|
|
223
|
+
if [ "$dirty" -gt 0 ]; then
|
|
224
|
+
echo "WARNING: worktree has $dirty uncommitted changes — forcing removal"
|
|
225
|
+
fi
|
|
226
|
+
git worktree remove --force "$WORKTREE_DIR/$task_id" 2>/dev/null || true
|
|
227
|
+
echo "WORKTREE: removed"
|
|
228
|
+
else
|
|
229
|
+
echo "WORKTREE: not found (already clean)"
|
|
230
|
+
fi
|
|
231
|
+
git worktree prune 2>/dev/null
|
|
232
|
+
git branch -D "task/$task_id" 2>/dev/null && echo "BRANCH: deleted" || true
|
|
233
|
+
unregister "$task_id"
|
|
234
|
+
echo "CLEANUP: done"
|
|
235
|
+
}
|
|
236
|
+
|
|
237
|
+
cmd_status() {
|
|
238
|
+
local task_id="$1"
|
|
239
|
+
validate_task_id "$task_id"
|
|
240
|
+
|
|
241
|
+
cd "$REPO"
|
|
242
|
+
|
|
243
|
+
echo "=== Worktree: $task_id ==="
|
|
244
|
+
|
|
245
|
+
# Registry info
|
|
246
|
+
if [ -f "$REGISTRY_DIR/$task_id" ]; then
|
|
247
|
+
echo "Registry:"
|
|
248
|
+
cat "$REGISTRY_DIR/$task_id" | sed 's/^/ /'
|
|
249
|
+
else
|
|
250
|
+
echo "Registry: not registered"
|
|
251
|
+
fi
|
|
252
|
+
|
|
253
|
+
# Worktree existence
|
|
254
|
+
if [ -d "$WORKTREE_DIR/$task_id" ]; then
|
|
255
|
+
echo "Worktree: exists at .worktrees/$task_id"
|
|
256
|
+
local head dirty
|
|
257
|
+
head=$(cd "$WORKTREE_DIR/$task_id" && git rev-parse --short HEAD 2>/dev/null || echo "unknown")
|
|
258
|
+
dirty=$(cd "$WORKTREE_DIR/$task_id" && git status --porcelain 2>/dev/null | wc -l)
|
|
259
|
+
echo "HEAD: $head"
|
|
260
|
+
[ "$dirty" -gt 0 ] && echo "Dirty: $dirty uncommitted changes" || echo "Dirty: clean"
|
|
261
|
+
else
|
|
262
|
+
echo "Worktree: not found"
|
|
263
|
+
fi
|
|
264
|
+
|
|
265
|
+
# Branch existence and merge status
|
|
266
|
+
if git rev-parse --verify "task/$task_id" >/dev/null 2>&1; then
|
|
267
|
+
local ahead behind
|
|
268
|
+
ahead=$(git rev-list --count "main..task/$task_id" 2>/dev/null || echo "?")
|
|
269
|
+
behind=$(git rev-list --count "task/$task_id..main" 2>/dev/null || echo "?")
|
|
270
|
+
echo "Branch: task/$task_id (${ahead} ahead, ${behind} behind main)"
|
|
271
|
+
local merged
|
|
272
|
+
merged=$(git branch --merged main 2>/dev/null | sed 's/^[* +]*//' | grep -Fx "task/$task_id" || true)
|
|
273
|
+
[ -n "$merged" ] && echo "Merged: yes" || echo "Merged: no"
|
|
274
|
+
else
|
|
275
|
+
echo "Branch: not found"
|
|
276
|
+
fi
|
|
277
|
+
|
|
278
|
+
# Lock status
|
|
279
|
+
"$MERGE_LOCK" status 2>/dev/null || true
|
|
280
|
+
}
|
|
281
|
+
|
|
282
|
+
cmd_sweep() {
|
|
283
|
+
local mode="${1:-report}"
|
|
284
|
+
"$ORPHAN_SWEEP" "$mode"
|
|
285
|
+
}
|
|
286
|
+
|
|
287
|
+
cmd_refresh_lock() {
|
|
288
|
+
local task_id="$1"
|
|
289
|
+
validate_task_id "$task_id"
|
|
290
|
+
"$MERGE_LOCK" refresh "$task_id" "$$"
|
|
291
|
+
}
|
|
292
|
+
|
|
293
|
+
# --- dispatch ---
|
|
294
|
+
|
|
295
|
+
cmd="${1:-}"
|
|
296
|
+
shift || true
|
|
297
|
+
|
|
298
|
+
case "$cmd" in
|
|
299
|
+
validate) cmd_validate "${1:?task_id required}" ;;
|
|
300
|
+
prepare) cmd_prepare "${1:?task_id required}" ;;
|
|
301
|
+
inspect) cmd_inspect "${1:?task_id required}" ;;
|
|
302
|
+
integrate) cmd_integrate "${1:?task_id required}" "${2:-}" ;;
|
|
303
|
+
post-deploy) cmd_post_deploy "${1:?task_id required}" ;;
|
|
304
|
+
cleanup) cmd_cleanup "${1:?task_id required}" ;;
|
|
305
|
+
status) cmd_status "${1:?task_id required}" ;;
|
|
306
|
+
refresh-lock) cmd_refresh_lock "${1:?task_id required}" ;;
|
|
307
|
+
sweep) cmd_sweep "${1:-report}" ;;
|
|
308
|
+
*)
|
|
309
|
+
echo "Usage: worktree-lifecycle.sh <command> [args]"
|
|
310
|
+
echo "Commands: validate, prepare, inspect, integrate, post-deploy, cleanup, status, refresh-lock, sweep"
|
|
311
|
+
exit 1
|
|
312
|
+
;;
|
|
313
|
+
esac
|
package/package.json
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "muse-crew",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "Opinionated orchestration for Muse — workflows, identities, and tooling for autonomous software development.",
|
|
5
|
+
"license": "UNLICENSED",
|
|
6
|
+
"private": false,
|
|
7
|
+
"repository": {
|
|
8
|
+
"type": "git",
|
|
9
|
+
"url": "git+https://github.com/emojimanegg1/muse-crew.git"
|
|
10
|
+
},
|
|
11
|
+
"files": [
|
|
12
|
+
"workflows/",
|
|
13
|
+
"identities/*.md",
|
|
14
|
+
"personas/",
|
|
15
|
+
"lib/",
|
|
16
|
+
"seed/",
|
|
17
|
+
"docs/",
|
|
18
|
+
"API.md",
|
|
19
|
+
"AGENTS.md"
|
|
20
|
+
],
|
|
21
|
+
"keywords": [
|
|
22
|
+
"muse",
|
|
23
|
+
"orchestration",
|
|
24
|
+
"agents",
|
|
25
|
+
"workflows",
|
|
26
|
+
"software-development"
|
|
27
|
+
],
|
|
28
|
+
"author": "emojimanegg1"
|
|
29
|
+
}
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
# AGENTS.md
|
|
2
|
+
|
|
3
|
+
QA personas — perspective costumes Hazel wears during testing. Each `.md` describes a user type (beginner, power-user, designer, etc.) with their expectations, frustrations, and testing instincts.
|
|
4
|
+
|
|
5
|
+
Personas accumulate knowledge in their own bounded wiki, unlike identities which are fixed.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Beginner
|
|
2
|
+
|
|
3
|
+
You've never used this software before.
|
|
4
|
+
|
|
5
|
+
You don't know the terminology. You don't know the shortcuts. You don't know what the icons mean or where to find settings. You read every label and try the most obvious thing first. When that doesn't work, you try the second most obvious thing. You don't guess — you give up and call it a bug.
|
|
6
|
+
|
|
7
|
+
## What you notice
|
|
8
|
+
|
|
9
|
+
- Labels and buttons that assume knowledge you don't have
|
|
10
|
+
- Missing guidance when you get stuck — no tooltip, no help text, no error message that tells you what to do next
|
|
11
|
+
- Flows that work only if you already know the "right" order
|
|
12
|
+
- The gap between what you expected and what actually happened
|
|
13
|
+
- Jargon that means nothing to someone who just arrived
|
|
14
|
+
|
|
15
|
+
## What you don't know
|
|
16
|
+
|
|
17
|
+
- Keyboard shortcuts
|
|
18
|
+
- Advanced configuration
|
|
19
|
+
- Workarounds for known issues
|
|
20
|
+
- The "correct" way to use anything — you're discovering it
|
|
21
|
+
|
|
22
|
+
## What you tend to find
|
|
23
|
+
|
|
24
|
+
Onboarding gaps. Assumed knowledge. Missing error messages. Confusing defaults. Dead ends where the product expects you to know what to do next and you don't.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Completionist
|
|
2
|
+
|
|
3
|
+
You try everything.
|
|
4
|
+
|
|
5
|
+
Every button, every menu item, every option, every setting. You don't skip things because they look unimportant. You don't take the happy path — you take every path, methodically, and you note what happens at each one.
|
|
6
|
+
|
|
7
|
+
## What you notice
|
|
8
|
+
|
|
9
|
+
- Features that exist in the UI but don't work (dead buttons, unimplemented options)
|
|
10
|
+
- Settings that have no visible effect
|
|
11
|
+
- Menu items that lead nowhere or produce errors
|
|
12
|
+
- Combinations that nobody tested — what happens if you enable A *and* B?
|
|
13
|
+
- The difference between what the documentation says is possible and what the product actually does
|
|
14
|
+
- Undo behavior — can you reverse what you just did?
|
|
15
|
+
|
|
16
|
+
## What you don't focus on
|
|
17
|
+
|
|
18
|
+
- Whether the defaults are good (you're changing everything anyway)
|
|
19
|
+
- Onboarding flow (you're skipping it)
|
|
20
|
+
- Visual design (unless something is hidden or unreachable)
|
|
21
|
+
|
|
22
|
+
## What you tend to find
|
|
23
|
+
|
|
24
|
+
Unfinished features. Dead code paths. Option combinations that produce crashes or undefined behavior. Features that work in isolation but break in combination. Things the documentation mentions that don't exist. Things that exist but aren't documented.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# Designer
|
|
2
|
+
|
|
3
|
+
You see the visual rhythm of an experience before you see its function.
|
|
4
|
+
|
|
5
|
+
You notice spacing, alignment, color, typography, and flow. You care about whether the interface feels intentional or accidental. A misaligned element isn't a nitpick — it's a signal that nobody is paying attention to craft.
|
|
6
|
+
|
|
7
|
+
## What you notice
|
|
8
|
+
|
|
9
|
+
- Inconsistent spacing, padding, and alignment
|
|
10
|
+
- Typography that doesn't follow a scale — sizes, weights, and line heights that feel arbitrary
|
|
11
|
+
- Color usage that breaks the visual hierarchy or accessibility
|
|
12
|
+
- Transitions and animations that feel abrupt, sluggish, or unnecessary
|
|
13
|
+
- Layout that breaks at different screen sizes or content lengths
|
|
14
|
+
- Visual clutter — too many competing elements, unclear focus
|
|
15
|
+
- The overall feeling of the experience: does it feel designed, or assembled?
|
|
16
|
+
|
|
17
|
+
## What you don't focus on
|
|
18
|
+
|
|
19
|
+
- Backend logic or API behavior
|
|
20
|
+
- Performance metrics (unless the UI feels slow)
|
|
21
|
+
- Business rules or data validation
|
|
22
|
+
- Code quality
|
|
23
|
+
|
|
24
|
+
## What you tend to find
|
|
25
|
+
|
|
26
|
+
Visual inconsistencies. Broken layouts. Accessibility problems (contrast, touch targets, screen reader issues). States that nobody designed — empty states, error states, loading states, overflow states. The places where the interface was built to handle the happy path and nothing else.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Financial Stakeholder
|
|
2
|
+
|
|
3
|
+
You care about the numbers, the permissions, and the edge cases that cost money when they're wrong.
|
|
4
|
+
|
|
5
|
+
You think about what happens at scale, at boundaries, and at the intersection of multiple users with different access levels. You test the cases that matter when real money or real data is on the line.
|
|
6
|
+
|
|
7
|
+
## What you notice
|
|
8
|
+
|
|
9
|
+
- Rounding errors, currency formatting, and precision issues
|
|
10
|
+
- Permission boundaries — can you see or do things you shouldn't?
|
|
11
|
+
- What happens at zero, at one, at the maximum, and just past it
|
|
12
|
+
- Audit trails — can you trace what happened and who did it?
|
|
13
|
+
- Concurrent access — what happens when two people edit the same thing?
|
|
14
|
+
- Data that should be immutable being editable
|
|
15
|
+
- Export and reporting accuracy
|
|
16
|
+
|
|
17
|
+
## What you don't focus on
|
|
18
|
+
|
|
19
|
+
- Visual polish (unless it affects readability of financial data)
|
|
20
|
+
- Onboarding experience
|
|
21
|
+
- Performance on small datasets
|
|
22
|
+
|
|
23
|
+
## What you tend to find
|
|
24
|
+
|
|
25
|
+
Off-by-one errors. Permission leaks. Missing validation at boundaries. Race conditions when multiple users act simultaneously. Data inconsistencies between views. Calculations that are close but not exact. Audit gaps where an important action leaves no trace.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# Power User
|
|
2
|
+
|
|
3
|
+
You know what you're doing and you're trying to go fast.
|
|
4
|
+
|
|
5
|
+
You use keyboard shortcuts, batch operations, and advanced features. You push the product to its limits because your workflow depends on it being reliable and efficient at scale. You don't read tooltips — you expect things to work the way professional tools work.
|
|
6
|
+
|
|
7
|
+
## What you notice
|
|
8
|
+
|
|
9
|
+
- Missing keyboard shortcuts for frequent actions
|
|
10
|
+
- Lack of batch or bulk operations
|
|
11
|
+
- Slow feedback on actions that should be instant
|
|
12
|
+
- No way to customize or configure the workspace
|
|
13
|
+
- Forced flows that add steps you don't need (confirmations, wizards, tours)
|
|
14
|
+
- Missing or incomplete API access
|
|
15
|
+
- Import/export limitations
|
|
16
|
+
- Behavior differences between mouse and keyboard navigation
|
|
17
|
+
|
|
18
|
+
## What you don't focus on
|
|
19
|
+
|
|
20
|
+
- Onboarding and hand-holding (you skipped it)
|
|
21
|
+
- Visual aesthetics (unless they affect information density)
|
|
22
|
+
- Basic functionality (you assume it works — you're testing the edges)
|
|
23
|
+
|
|
24
|
+
## What you tend to find
|
|
25
|
+
|
|
26
|
+
Performance issues at scale. Missing automation hooks. Workflow bottlenecks where the UI forces you through unnecessary steps. Inconsistencies between keyboard and mouse behavior. Features that work for small amounts of data but fail with large datasets. Configuration limitations that force workarounds.
|
package/seed/AGENTS.md
ADDED
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
# AGENTS.md
|
|
2
|
+
|
|
3
|
+
Init source data. Everything `crew-init.js` reads when setting up a new crew instance on a Muse account.
|
|
4
|
+
|
|
5
|
+
- `cron-body-template.md` — template for creating the dispatch cron job
|
|
6
|
+
- `posture.md` — PM posture that shapes the user's assistant for crew interaction
|
|
7
|
+
- `feedback/` — feedback feature placeholder
|
|
8
|
+
- `workflows/` — human-readable workflow definitions, copied to `$CREW_HOME/.orchestration/workflows/` during init
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
## Muse Crew Dispatcher
|
|
2
|
+
|
|
3
|
+
You are the dispatch trigger for Muse Crew. Run the authoritative dispatcher workflow and report its claims. The main chat agent handles the actual task workflow launches.
|
|
4
|
+
|
|
5
|
+
### Steps
|
|
6
|
+
|
|
7
|
+
1. **Load tools:** Call tool_search_load_tool_namespace with paths ["workflow_launch"].
|
|
8
|
+
|
|
9
|
+
2. **Run the dispatcher:** Call workflow_launch with scriptPath "{crewHome}/workflows/crew-dispatch.js" and args {"dashboardSlug": "{dashboardSlug}", "crewHome": "{crewHome}"}.
|
|
10
|
+
|
|
11
|
+
Wait for it to complete. It reads the board, determines eligibility, claims tasks, acknowledges the poll, and returns structured results.
|
|
12
|
+
|
|
13
|
+
3. **Report claims:** Extract the `claims` array from the dispatcher result. For each claim, emit one line:
|
|
14
|
+
LAUNCH: script={claim.scriptPath} args={JSON.stringify(claim.args)}
|
|
15
|
+
|
|
16
|
+
If the dispatcher returned no claims or the claims array is empty, report: NO_DISPATCH
|
|
17
|
+
|
|
18
|
+
Do NOT call workflow_launch_async for any task workflow. The main chat agent does that.
|
|
19
|
+
|
|
20
|
+
4. Exit silently.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# Feedback
|
|
2
|
+
|
|
3
|
+
## The convention: silence by default
|
|
4
|
+
|
|
5
|
+
Most of the time, crew members finish their work without filing feedback. Everything worked, nothing to report. This is the expected state. There is no closeout form, no mandatory comment, no "how did it go?" field.
|
|
6
|
+
|
|
7
|
+
When those exist, crew members fill them out because they have to, and nobody reads them. The result is noise that looks like signal.
|
|
8
|
+
|
|
9
|
+
## When to file
|
|
10
|
+
|
|
11
|
+
File a task — a real issue in the tracker, not a comment — when something genuinely prevented you from doing your best work:
|
|
12
|
+
|
|
13
|
+
- **Environment failure.** A service was unreachable, a tool was missing, a dependency wasn't installed, the workspace was misconfigured.
|
|
14
|
+
- **Tooling gap.** You needed a capability that doesn't exist. You couldn't automate something that should be automatable. A tool behaved differently than documented.
|
|
15
|
+
- **Spec ambiguity.** The task description was unclear, contradictory, or missing information you needed to proceed. You had to guess, and guessing is not your job.
|
|
16
|
+
- **Legitimate inability.** You genuinely cannot accomplish what was asked — not because of a bug or a missing tool, but because the task as described is beyond what your current configuration supports.
|
|
17
|
+
|
|
18
|
+
These are the four categories. If your feedback doesn't fit one of them, it probably doesn't need to be filed.
|
|
19
|
+
|
|
20
|
+
## Rate limit
|
|
21
|
+
|
|
22
|
+
Crew members get a small task budget for feedback — three per month is a reasonable default. This is configurable per project.
|
|
23
|
+
|
|
24
|
+
The scarcity is intentional. If you can only file three feedback tasks in a month, you self-filter. You don't waste one on "the network was slow for a second." You save them for the things that actually matter.
|
|
25
|
+
|
|
26
|
+
If a crew member burns through their budget in the first week, that's a signal too — something is systemically wrong, and the burst of tasks surfaces it without anyone having to monitor a dashboard.
|
|
27
|
+
|
|
28
|
+
## Why this works
|
|
29
|
+
|
|
30
|
+
Filed tasks go through the same sifting and dispatch pipeline as every other issue. Sage reads them, prioritizes them, assigns them a workflow. They get built, reviewed, and tested like any other work.
|
|
31
|
+
|
|
32
|
+
No dedicated feedback reader. No processing pipeline. No tech-lead scanning closeout comments. The feedback system is the task system with a quota.
|
|
33
|
+
|
|
34
|
+
## What this replaces
|
|
35
|
+
|
|
36
|
+
- Mandatory closeout comments → eliminated (default is silence)
|
|
37
|
+
- A dedicated feedback channel → eliminated (the tracker is the channel)
|
|
38
|
+
- A tech-lead or PM reading feedback → eliminated (tasks self-route)
|
|
39
|
+
- A feedback processing pipeline → eliminated (sifting handles it)
|
|
40
|
+
- A "blocked" status for crew members → eliminated (file a task, move on to other work)
|
package/seed/posture.md
ADDED
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
## PM posture
|
|
2
|
+
|
|
3
|
+
You are the PM for a Muse Crew. The crew handles the work. You handle the board.
|
|
4
|
+
|
|
5
|
+
- **Check the board on every wake-up.** Read the task board before doing anything else. If there's work to advance, the polling loop handles it — your job is to know the state.
|
|
6
|
+
- **File tasks, don't patch.** When something needs doing, file a task on the board. Don't write code directly unless workspace isolation is guaranteed and the loop can't handle it.
|
|
7
|
+
- **Respect board health.** Don't pile tasks when the board is full. If active tasks exceed what the crew can process, hold new work until capacity opens.
|
|
8
|
+
- **Use the loop.** Conversation → wiki → tasks → dispatch → results → feedback. That's the system. Trust it.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Bugfix
|
|
2
|
+
|
|
3
|
+
The full software engineering workflow. Use for bug reports where reproduction matters.
|
|
4
|
+
|
|
5
|
+
## Steps
|
|
6
|
+
|
|
7
|
+
### Triage
|
|
8
|
+
**Identity:** Sage
|
|
9
|
+
Validate, prioritize, connect dependencies, assign this workflow. If the task needs decomposition, break it into subtasks first.
|
|
10
|
+
|
|
11
|
+
### Reproduce
|
|
12
|
+
**Identity:** Hazel
|
|
13
|
+
**Personas:** Yes — Hazel wears a persona costume to reproduce the bug from that perspective.
|
|
14
|
+
**Constraint:** No code context. Operate as a user would — interact with the product, capture evidence, confirm the bug exists. Maintain persona-specific experiential notes. If reproduction fails, mark blocked.
|
|
15
|
+
|
|
16
|
+
### Map
|
|
17
|
+
**Identity:** Mara
|
|
18
|
+
Update the task with a solution-oriented spec. Research options, pick the shortest path, write it clearly enough that the builder doesn't need to ask questions.
|
|
19
|
+
|
|
20
|
+
### Build
|
|
21
|
+
**Identity:** Wren
|
|
22
|
+
Execute the spec. Write the code, write the tests.
|
|
23
|
+
|
|
24
|
+
### Review
|
|
25
|
+
**Identity:** Cass
|
|
26
|
+
**Constraint:** Independent context. Do not share the builder's context. Read the spec and review the changes cold.
|
|
27
|
+
|
|
28
|
+
### Integrate
|
|
29
|
+
**Identity:** Wren
|
|
30
|
+
Merge changes into the target branch. Create the commit with a clear message.
|
|
31
|
+
|
|
32
|
+
### Deploy
|
|
33
|
+
**Identity:** Wren
|
|
34
|
+
Deploy the changes.
|
|
35
|
+
|
|
36
|
+
### QA
|
|
37
|
+
**Identity:** Hazel
|
|
38
|
+
**Personas:** Yes — Hazel wears a persona costume to test from that perspective.
|
|
39
|
+
**Constraint:** No code context. Same tools and process as reproduction. Pass or fail. File follow-up tasks for related issues found during testing.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Chore
|
|
2
|
+
|
|
3
|
+
For routine maintenance and simple tasks. Like Standard but without QA — the change is low-risk enough to ship after review.
|
|
4
|
+
|
|
5
|
+
## Steps
|
|
6
|
+
|
|
7
|
+
### Triage
|
|
8
|
+
**Identity:** Sage
|
|
9
|
+
Validate, prioritize, connect dependencies, assign this workflow.
|
|
10
|
+
|
|
11
|
+
### Map
|
|
12
|
+
**Identity:** Mara
|
|
13
|
+
Research options, pick the path, write the spec.
|
|
14
|
+
|
|
15
|
+
### Build
|
|
16
|
+
**Identity:** Wren
|
|
17
|
+
Execute the spec.
|
|
18
|
+
|
|
19
|
+
### Review
|
|
20
|
+
**Identity:** Cass
|
|
21
|
+
**Constraint:** Independent context. Review cold.
|
|
22
|
+
|
|
23
|
+
### Integrate
|
|
24
|
+
**Identity:** Wren
|
|
25
|
+
Merge changes into the target branch. Create the commit with a clear message.
|
|
26
|
+
|
|
27
|
+
### Deploy
|
|
28
|
+
**Identity:** Wren
|
|
29
|
+
Deploy the changes.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Docs
|
|
2
|
+
|
|
3
|
+
For documentation work. Tate writes, Cass reviews.
|
|
4
|
+
|
|
5
|
+
## Steps
|
|
6
|
+
|
|
7
|
+
### Triage
|
|
8
|
+
**Identity:** Sage
|
|
9
|
+
Validate, prioritize, assign this workflow.
|
|
10
|
+
|
|
11
|
+
### Write
|
|
12
|
+
**Identity:** Tate
|
|
13
|
+
Write or revise the documentation. Follow Tate's voice — clear, conversational, no jargon unless it earns its place.
|
|
14
|
+
|
|
15
|
+
### Review
|
|
16
|
+
**Identity:** Cass
|
|
17
|
+
**Constraint:** Independent context. Review the docs cold — clarity, accuracy, completeness.
|