How OpenScaffold works

OpenScaffold helps deployment teams get customers live faster. It makes sense of scattered customer context, keeps implementations on track, and turns what works into reusable playbooks. Each deployment has four tabs: Overview, then one per step below. Anything waiting on you sits under Needs you at the top of the tab it belongs to, only when there’s something.

​

1. Understand the customer

What it does. Turns the customer’s scattered calls, emails, tickets, docs and decisions into one living model of what they need and why: their rules, people, systems and the words they use, plus the plan. Every item quotes the customer word for word; a quote that isn’t really in the source is thrown away. New material becomes a proposed plan change, never a silent edit. In the app. The Customer tab, with Sources (the evidence) inside it. Needs you: plan changes from new customer material, questions to ask the customer, sources that failed. What the agent does. Your coding agent loads the customer at the start of a session (the briefing) and calls search, get_profile and get_person before assuming anything about a requirement, system or term.

​

2. Build it right

What it does. Uses that model to break the work down: each in-scope plan item is a work item, with what exists today, what to build, and the customer’s words for it. It keeps agents aligned with the customer’s requirements and past decisions, and checks their work before anything ships: your coding agent writes the change, OpenScaffold’s reviewer checks it. In the app. The Build tab: the plan, grouped Not agreed yet, Agreed, Building, Done, plus what’s out of scope. Each review has its own page under Build. Needs you: plan changes from coding-agent sessions, and reviews that need changes. What the agent does. Builds from get_plan, cites what it relies on, proposes plan changes with propose_change when it finds something new, and calls request_review with its diff before it finishes (or when you say “check my work”). It reports back with report_session.

​

3. Reuse what worked

What it does. Captures what worked on one deployment as entries in your team’s playbooks (setup steps, environments, domain knowledge, caveats, links) and brings them into the next deployment doing the same kind of work. Playbooks never hold customer data: every entry is checked for names, people, domains, systems, terms and copied passages, and refused if it has any. In the app. The Playbooks tab: the playbooks this deployment uses, caveats first. Needs you: a suggested playbook (Use these), and new entries waiting for an admin. What the agent does. Reads get_playbooks and follows the caveats. Uses a suggested playbook with use_playbooks (playbooks only add guidance; remove any under Playbooks). Proposes what it learned with propose_playbook_entries; an admin approves.

​

The review

The writer never grades itself. When your coding agent calls request_review (or you run check-plan, or just say “check my work”), a separate reviewer on OpenScaffold’s side reads the diff. It checks adherence to the customer, not code quality: it doesn’t hunt for bugs. It never runs your code. A review takes 30–50 seconds; the agent waits for it in one call. What’s checked

• Claimed work items: does the change do the plan items it says it works on, the way the customer asked?
• Customer rules: hosting, data access, security, process.
• Customer terms: code uses the customer’s definitions (what they mean by “late”, for example).
• Out of scope: anything the customer said not to build.
• Playbook caveats: lessons from the playbooks this deployment uses.

Verdict The verdict is computed in code from the findings that survive the checks below, not taken from the model. Per work item: Met, Partly met (with what’s missing), Not met (with what’s absent), or Needs a manual check (the diff can’t show it, such as UI or config; with what to check). Findings point at file:line in the diff. Every finding quotes the customer word for word, and the quote is verified against their documents before it’s stored; a finding whose quote can’t be verified is dropped. No customer words, no finding. Where you see it. Your agent shows you the review and fixes blockers and issues, then asks for a new one. In the app, the review is on Build: its own page with the summary, each work item, and findings inline under their lines in the diff, each quote linking to where the customer said it. A review that needs changes shows under Needs you. When a review is Ready, you can Mark done the work items it covers; nothing is marked done without you.