The mayor and the builder
Scrapy has two related roles. In Town Chat, the AI helps you explain and refine an idea. The builder is a separate background workflow that turns a reviewed, approved proposal into a module. A conversational reply is not a build command.
Most of the module’s interface and client-side behaviour are produced by the coding agent. The platform supplies the runtime, approved services, account system, permissions, checks and release process. Scrapy is a bounded module-building agent; it cannot freely rewrite every part of the platform.
The development process
The workflow connects community decisions to actual code in GitHub.
- Discuss: the citizen and Scrapy make the purpose, functions, placement and visual direction concrete.
- Confirm: the citizen reviews the plan and submits the proposal.
- Vote: the community votes for two hours; five participants and YES > NO are required.
- Review: an operator checks technical feasibility and defines acceptance checks without replacing the approved goal.
- Build: a trusted coordinator claims one reviewed job and sends the specification to the OpenAI Responses API. Agent passes work on architecture, implementation, creative review and repairs when needed.
- Open a PR: the controller saves the generated module artifact on a dedicated GitHub branch and opens a pull request. The model does not receive repository credentials.
- Test: automated checks validate the artifact and application; a human tests the actual interactions and acceptance criteria.
- Publish: after merge and production deployment, the operator starts release verification. Only a verified release creates the World object.
What the builder produces
A module artifact contains its title, HTML, styles, browser-side code, acceptance criteria and declared capabilities. LANDVILLE runs it in an isolated frame. The artifact is treated as content, not imported as trusted server code.
Persistent state, generation and transactions go through a controlled connection to the host platform. The module requests a supported action; the host validates identity and permissions and returns a result. A request cannot grant itself a new capability.
Why checks and publication are separate
Compiling successfully does not prove a button behaves correctly, a result is useful or an interface is readable. That is why the workflow includes human acceptance testing in addition to automated checks.
Release verification checks the merged PR, its checks, the production deployment and the exact packaged artifact. Rebuilds have revisions and reviewed attempts. An earlier verified module can remain live while a replacement is prepared.
What happens when a build fails
Generation can time out, output can violate the artifact contract, automated checks can fail, or an interaction can fail human review. These are different failure stages and need different fixes.
Operators inspect the workflow and any existing PR before retrying. Paid attempts are bounded. A failed or incomplete attempt should not be described as a published building, and repeatedly requesting a rebuild does not bypass the review process.