Method: building an evidence-gated artifact with Majordomus

What was built

The site is a bilingual static publication generated with Zola, deployed to GitHub Pages and verified against the live URL on every change. It was produced in a single working session by an AI coding agent (Claude Code) directed by one person, with Majordomus as the supervisory layer between the agent and the repository.

This note documents that process with the same standard the research notes apply to psychology: report what was measured, separate it from interpretation, and state what cannot be concluded.

The recorded timeline of the first release

All times are UTC on 14 September 2026 and come from the Git history, the GitHub API, the Majordomus ledger and the pipeline records.

Derived durations:

• repository creation to first verified release: 51 min 36 s
• Majordomus initialisation to first verified release: 19 min 19 s
• push to verified release: 2 min 57 s

At that release the site was checked by 7 validation stages and 30 browser tests. Later phases (link previews and structured data, then this research library and the advice library) followed the same loop and are visible in the repository’s release history.

The kinds of instructions

The work was driven by about fifteen messages from one person. They fell into five types:

1. A one-line request to create a project on GitHub.
2. Art direction for the poster, followed by a choice between three offered approaches.
3. Structured execution briefs. Three long specifications of increasing scope: a static artwork page, an interactive microsite, and a multilingual publishing system with dozens of numbered requirements and an explicit completion gate.
4. Short directives during work: deploy, validate in a browser, release automatically, use Majordomus and enforce it.
5. Editorial direction: apply HTML5 Boilerplate practices, improve link previews and search visibility, and replace promotional copy with serious, sourced psychology.

None of these messages specified implementation details such as template syntax or test cases. Those were decisions of the agent, and the supervision layer’s job was to keep them checkable.

What Majordomus contributed

Majordomus did not write code. It constrained and recorded the work:

• Scoped tasks. Every change ran as a task with declared paths. When files were moved outside that scope, majordomus watch reported drift, and the task was restarted with a correct scope. When a later scope was malformed, majordomus check reported every file as out of scope before the push, which would otherwise have been refused by the pre-push hook.
• A health check on every commit. majordomus doctor runs in the pre-commit hook. Before the first commit it reported that the README did not link the agent bootstrap file; the defect was fixed before it reached the repository.
• A finish contract. majordomus finish refuses to close a task as completed unless its verification command passes. For this site that command is the live smoke test, so “completed” means “deployed and checked”, not “written”.
• Continuity. Checkpoints and handovers recorded the current state and the next action whenever a task was restarted, so each restart took seconds and depended on recorded facts rather than on the agent’s memory.
• Rules in the repository. Project rules such as “no deployment claim without live verification” live in .ai/repo/rules/, next to the code they govern.

Did it make development faster?

The honest answer is that no speed-up factor can be stated. There was one session and no comparable session without supervision, so there is no control condition.

What the records do show is where time was not lost. No push was rejected by CI, no deployment had to be rolled back, and the first pipeline run passed all seven jobs. Three defects (two scope errors and a documentation bootstrap failure) became local findings instead of failed pipeline runs. Each would have cost at least one additional push-and-wait cycle of several minutes, and a failed deployment would have cost more.

The larger effect is on confidence rather than raw speed. Every “done” in this project is backed by a recorded command and its exit code, which a reader can check with majordomus history in the repository.

Limits of this account

• The timeline starts at the first recorded file; planning that happened before it is not included.
• Durations depend on the tools, the hardware and network latency of this session.
• The session also relied on conventional safeguards unrelated to Majordomus, including local validation, browser tests and continuous integration. Their effects are not separated here.