Artefacts
Background operator artefacts
These are not yet Build Loop proof. They are adjacent operator evidence: agent-readable feedback, visible workflow state, product surfaces, and policy-aware implementation. Direct Build Loop proof should come from dogfooding the framework itself.
How to read this page
This page remains as background credibility for Reworking Order. The Build Loop homepage should not overclaim these artefacts as direct proof until a visible Build Loop trace exists.
Artefacts
Tooling and projects
A live board for multi-window work. The system is small, but it makes workflow visible and actionable.
The detail overlay turns a ticket into a working spec with criteria, smoke checks, learnings, and attachments.
Ticket creation happens inside the same operating surface rather than being split into a separate planning tool.
ticket-takeaway
Tooling for building webapps with agents needs more than prompt helpers. It needs an operating surface that keeps tickets, state, review, and handoff aligned while people and models work in parallel.
What was tested
The repo started on March 26, 2026 as a markdown-native board rendered from `PRODUCT_BACKLOG.md`. By March 29 it had migrated to SQLite with a CLI, sync layer, and installer so multiple agent windows could work against the same project state without losing the legibility of markdown.
What was learned
The leverage was not in issuing more prompts. It was in building a durable coordination layer: explicit ticket states, live dashboard updates, review gates, attachments, and a workflow that survives both direct markdown edits and agent-driven changes.
Evolution
Milestone 01
Started as a markdown-native kanban board
The initial commit treated `PRODUCT_BACKLOG.md` as the artefact and rendered it into a dashboard rather than replacing it with a heavier project-management system.
Milestone 02
Migrated to SQLite without abandoning markdown
A CLI, sync layer, and installer moved the source of truth into SQLite while keeping markdown as the public and agent-readable surface.
Milestone 03
Became an actual runtime
A zero-dependency HTTP server, inline editing, AI gate checks, and a growing test framework turned the board from a generator into working infrastructure.
Milestone 04
Presentation caught up with capability
Scenario-driven screenshots and theme support made the tool easier to explain publicly without changing the underlying workflow logic.
Reviewed directly
The active recording state keeps screen capture, spoken feedback, and review context in one operating surface while the session is being created.
After capture, the session moves into transcription so screenshots and spoken feedback become structured evidence an agent can inspect.
Reviewed in code
Live agent bridge
The MCP server turns saved sessions and live capture into tools rather than inaccessible files.
feedbacks-mcp
Review tooling for webapps should capture what the reviewer saw, what they said, and where they pointed, then expose that session in a form an agent can actually work with.
What was tested
The first version was a browser-based screen-and-voice capture tool. The harder second step was reliability: local whisper bootstrapping, speech-aware chunking, transcript hygiene, and a live MCP bridge so review could move from raw recording to agent-readable evidence.
What was learned
The difficult part is not multimodal capture itself. It is alignment: rejecting silence, preserving the visual context around speech, and structuring the output so an LLM can inspect the session instead of merely being told that one happened.
Evolution
Milestone 01
Initial capture loop
The repo began as a screen-and-voice capture tool for UI feedback sessions, already oriented toward AI analysis rather than generic recording.
Milestone 02
Reliability became the design problem
Decision 001 documents the removal of descriptive whisper prompts after hallucination problems and the move toward VAD as the primary guardrail.
Milestone 03
Local transcription was operationalized
`server.py` grew into an all-in-one launcher that can find, install, and run whisper.cpp locally while proxying transcription requests.
Milestone 04
Sessions became speech-anchored instead of time-sliced
Client-side VAD, anti-hallucination filtering, and a speech-anchored timeline made the output much more useful for downstream analysis.
Milestone 05
The repo turned into a live review interface for agents
An MCP server exposed session history and live capture streams directly inside Claude Code, bridging browser review and agent action.
Milestone 06
Capture became embeddable
Recorder widget mode made feedback capture easy to launch from other apps, which is what turned the tool from standalone utility into reusable infrastructure.
Reviewed directly
A map-first operations surface where dispatch, search, task load, and field coordination sit in one working view.
GoodForm
GoodForm is hands-on operator product work: a field operations platform where workflow strategy, dispatch design, task logic, and implementation moved together rather than in separate consulting and delivery tracks.
What was tested
Across the product's growth, the work kept expanding from task-and-form foundations into dispatch control, reporting, repeatable process design, and mobile field execution. It was also developed because the client wanted a base for tracking data that would underpin an agentic workflow once the underlying structure and process were stable enough to automate cleanly.
What was learned
Operator work is strongest when strategy and implementation stay coupled. The leverage came from deciding what operating model the product should support, then building the surfaces and data structure that could later carry AI automation once the process was bedded down.
Evolution
Milestone 01
Repository opened as a product foundation
The project started as a product foundation rather than a one-off build, which shaped both the ambition and the pace of refinement.
Milestone 02
Reporting and dependency logic became first-class
Operational reporting and dependency logic became part of the product itself rather than an afterthought around task handling.
Milestone 03
Process templates were added on top of tasks
The product moved from isolated task handling toward repeatable operational design, with reusable process structure layered over daily execution.
Milestone 04
Stabilization and system operations came into focus
The later phase focused on hardening, access cleanup, and operational reliability, which is usually the point where a real product stops being a prototype.
Reviewed directly
Private repository reviewed directly. The proof here stays at the level of product surfaces and operating learnings rather than disclosing internal architecture or source code.
The live dial surface stays intentionally spare. The point is not decorative telephony chrome, but a calling surface that can sit on top of routing, pricing, and policy logic.
The surrounding account surface shows the rest of the product system: credits, rates, account controls, and the operating edges around the dialer itself.
Reviewed in code
Call policy layer
The product logic is not only telephony plumbing. It is the policy layer that decides whether a call should proceed and under what conditions.
Reviewed in code
Billing control model
Billing is handled as an explicit control surface with reservations, settlement, recovery, and audit checks rather than as a hidden side effect.
PhoneApp
PhoneApp was a proof of concept for a telco operator that wanted to see how AI tools could be used to create a new product set around browser-based communications.
What was tested
The proof combined a lightweight calling surface with the less visible work required to make communications software commercially real: permissions, billing rules, route handling, and policy correctness. The test was whether AI-assisted product work could move quickly while still producing a coherent operating model underneath the dialer.
What was learned
In communications products, the strategy lives inside the constraints. What mattered was not just whether the dialer worked, but whether the concept could hold pricing, permissions, routing, exceptions, and trust in one coherent system.
Evolution
Milestone 01
Repository opened around a browser-phone product
The product began with a full-stack communications ambition, but the real challenge quickly shifted from interface novelty to operating correctness.
Milestone 02
Billing moved onto an explicit ledger and reservation model
The business logic was made more explicit so spend, reservation, and settlement could be reasoned about as part of the product rather than as incidental backend behavior.
Milestone 03
Security and product readiness were reviewed together
Security and product readiness had to be reviewed together, which is usually the point where communications software stops being a demo and starts becoming a real operating system.
Milestone 04
Policy correctness became the next frontier
The later work focused on tighter policy handling, safer exception paths, and cleaner operating constraints, which reads like product maturation rather than contract delivery.
Reviewed directly
Private repository reviewed directly. The proof here is kept at the level of product surface and category-level operating logic rather than internal architecture.