One Form Row to a Working Intake System: Processing Sigrun’s First Website Request

Jagoda Pasko submitted the test entry for Sigrun’s Personal Brand Website request form on July 16 at 12:31. The next morning, one agent session took it from “row in a sheet” to a working system: entry validated, an email-killing DNS trap caught, status posted to the client-visible Basecamp thread, a daily 4:45am intake agent scheduled, and the definitive article published so any group can run the same process. This meta article documents how, including two gotchas the next agent needs.

What shipped

• Definitive article: How Any Group Gets Personal Brand Websites for Its Members — the form fields, the nine-stage status pipeline, the DNS email-safety branch, and the run-it-for-your-group checklist.
• Status post in Basecamp: the full report on the test entry, posted to the Updates thread where Jagoda, Sigrun, and the team already work, in the per-member status format every future submission will use.
• Daily intake agent: scheduled at 4:45am — scans the sheet for new rows, runs dig checks (NS, A, MX, SPF), advances statuses, posts to Basecamp only when something changed, and stages any member email as a draft for human send.
• Request ledger: a JSON file the agent maintains so no row is ever processed twice and every status change has a record.

The catch that justified the whole test

The form asks “does your domain already run your email?” Jagoda answered yes, and the MX lookup confirmed live mail on her domain. The form also told members to add 4 nameserver records before submitting. Those two things together are how a member loses their inbox: a nameserver switch with no mail records in the new zone silently kills email. The fix went into the process, not just her case — members with live email get the A-record path, and nameservers are only ever issued per-site, after provisioning. One test submission, one production incident prevented.

Gotchas for the next agent

1. Basecamp’s Lexxy editor would not submit. Typed content registered (2,431 chars in the contenteditable, the form-associated lexxy-editor element carried name="comment[content]"), but button clicks and form.requestSubmit() both did nothing, silently. The fix that works: grab authenticity_token from the comment form and POST directly to the form action (.../recordings/{id}/comments) with URLSearchParams carrying authenticity_token and comment[content] as HTML. Returns a 200 redirect back to the thread; reload to verify the new recording appears. Comment posts under the logged-in user.
2. Gmail draft editing is still blocked by an extension iframe. Clicking a draft row hands the tab context to a third-party compose extension and every tool call after that errors. Same behavior as documented on the July 14 build. Don’t fight it: connector-created drafts are write-once, so get them right the first time, and treat “edit an existing draft in the UI” as a human step.

Ship order matters

The definitive article published before the Basecamp status post, so the post could link it. Documentation that ships with the work gets read; documentation promised for later doesn’t exist.

Process: the definitive article. Standard this post follows: the meta article prompt.