SensorSynthFM:
The Build
Process
What This Page Is
This is a process record for an ongoing build. It does not claim that SensorSynthFM is done, that sensors are already flowing into audio, or that the task system is automatic. The page shows how the work is being scoped and checked while the product itself is still in development. It should keep changing as the project changes, then stand as a retrospective of how the work actually happened.
The Kanban board is evidence because it exposes the shape of the work: research gates, implementation tasks, blocked decisions, and review steps. It is not a raw project-management dump. Private task bodies, logs, file paths, task ids, and worker names are abstracted before anything is shown here.
Current Board Snapshot
The image below is generated from the live SensorSynthFM process board. It now reads left to right, from scheduled and todo work toward completed evidence. It renders only public card titles, status, priority, and abstracted lane labels. The receipt beside the image records when it was generated and what was intentionally omitted.
public/images/sensorsynthfm/process/kanban-current.receipt.json.How This Becomes a Retrospective
The page is meant to improve during the project, not freeze the first snapshot. Each substantial milestone should add one short process note: what changed, what evidence mattered, what was deferred, what broke, and what decision came next.
- Refresh the board image. Regenerate the snapshot after public-relevant Kanban milestones so the page reflects the real working sequence.
- Preserve the decision trail. Keep the capstone gates, research pages, review cards, and approval boundaries visible enough that the final case study can explain how the work was made.
- Keep failure useful. Blocked cards, review friction, and scope cuts should remain part of the record when they explain the final shape of the instrument.
Completed Process Gates
The current completed stewardship lane matters because it keeps ambition from outrunning evidence. Four gates are already visible in the snapshot:
- Capstone evidence gate: Confirmed the capstone framing before treating the project as coursework evidence.
- Parked ambition register: Separated later ambitions such as sequencer, MPE, AUv3, and Ableton Link from the thesis-demo scope.
- Peer feedback cleanup: Cleaned or preserved support assets so feedback can inform the build without leaking private context.
- Discovery research gate: Defined the target player, situation, and research questions before turning the app into a demo plan.
What the Board Proves
Small cards
The work is split into bounded tasks with visible status instead of one vague promise to build the whole instrument.
Verification gates
Review, evidence, and approval cards sit beside implementation cards, so process evidence is part of the work.
Honest friction
Blocked, scheduled, and todo cards stay visible. A clean-looking board would be less useful than a truthful one.
Human boundary
James keeps the framing and publish decisions. Agents can execute tasks, but public changes still wait for review.
Public-Safety Rules
The useful story is the workflow pattern, not the private machinery. Every refresh of this page should keep these boundaries intact:
- Abstract private internals. Show public labels, not raw task ids, worker names, local paths, logs, or chat excerpts.
- Explain Kanban as evidence. The board proves scoped work, review friction, and decision gates. It is not decoration.
- Avoid finished-product language. The product page already says what is not working yet. This page should preserve that honesty.
- Preserve James's approval boundary. Agents can help execute and review tasks, but public publishing still waits for James.