Vibe coding means constant change with nobody managing it: no sprint, no gate review, no launch date to hang a checklist on. Checklists such as the OWASP Top 10 already say what to secure. What is missing is when: which event, noticed as it happens, makes a given safeguard due.

The answer here is that hardening comes due when work moves to a new context. A move raises the work's audience or its lifetime, or changes the authority it runs with. A move is an event an agent can detect, where a launch date or a user count is not.

The evidence is one repository's: experiments 016 and 017 of a Bombadil and Clojure lab, where a ticket-sales app called eventstr was built and broken on purpose. One repository is enough evidence for a skill; a synthesis needs two. See Limits.

Live mutants sorted agent work by Getting Things Done context. For hardening, what matters is less what each context can build than what it starts with.

All the evidence below comes from context 3, the one with the most ambient authority and the fewest built-in safeguards. The triggers are written for it.

Three rules about the direction of a move fall out of the table:

• Moving into context 3 is a trigger in itself. A scaffold from chat that lands in your working directory gains authority it never had, so keeping secrets out of it is due then, not later.
• Moving from 3 to 4 is the cheapest hardening there is. A clean sandbox makes every secret, path and dependency nobody declared fail loudly. The move takes the inventory for you.
• Moving up the table needs no hardening, only a reseal. When evidence goes back into a chat or a spec, write down the rule the run taught you.

Each trigger is a fact about the new context, not a judgement about quality, and each was earned by a failure.

For each true trigger the minimum evidence is a safeguard seen to fire: kill the process, rename the field, unmount the route, leak a record into the view, blind the check, skip the deploy. A safeguard nobody has watched fail is a hope.

The triggers ship as a staging skill, harden-on-context-change, in the house skills repository, with five behavior evals not yet run.

The triggers fire at moves. Work that has already moved keeps decaying (Lehman's point, below), and nothing re-fires them. SRE's error budget is the mechanism built for this: a service promises a level, measures against it, and when the budget is spent, reliability work takes priority over features.

A coordinator agent working in context 3 can carry the same thing, but not as a reminder in its prompt. "Consider error budgets" is a prose rule of the "be careful with secrets" kind, and context 3 keeps nothing across sessions except files. The error budget's working parts are mechanical:

1. Declare the promise at the move. When the triggers are checked, write one ledger row in the repository: what the work promises, where that is measured, the budget, the owner. For example: "the eventstr clean run stays silent; source runs/; one unexplained failure per 20 runs; owner: me". Rows are written only at moves, so the rule against hardening what isn't moving still holds.
2. Measure from evidence that already exists. Agent work has its own measures: false alarms in clean runs, checks that report they never ran, "waiting for" items older than N days, background jobs that hit the cap.
3. Have a policy that preempts. When a budget is spent, the coordinator opens an issue and starts no feature work on that item until it is closed. That rule is what makes a budget a budget and not a dashboard.

The check belongs in a script the coordinator runs at session start or weekly review, with the ledger in the repository. A watcher in context 3 dies with the session, which is the dashboard failure again.

The parts are all well studied. Less common is the trigger: the literature mostly keys hardening to a date (a launch, a gate review) or a scale (users, a spent budget).

Practitioner guides say what to secure. Engadget's beginner list for vibe coding (2026-11-01) is typical: write a specific spec and a rules file, keep keys out of chat and code, parameterize queries and use row-level security, rate-limit, and review. Against the six triggers it adds three gaps (secrets, supply chain, rate limiting) that nothing in the lab repository has yet failed on. It also disagrees on one: having a model review its own work, with no planted fault, is the check that reports clean. Use a checklist once a trigger has fired, and take its numbers from primary sources; the guide's "four times as productive, ten times the security issues" comes from a security vendor.

Most hardening work in practice is a transfer: an app built in one context is moved to another. A prototype from a hosted agent platform goes into a repository, or a repository's service goes into a sandbox or onto a cloud platform. The rule for a transfer follows from the contexts table: whatever the source context gave for free becomes owed, and whatever the target gives for free can be dropped.

A hosted agent platform hands over a running app with deploy, secrets and a URL already solved, and nothing that says what the app is supposed to do. Moving it into a repository loses the first three and gains nothing on the fourth unless someone writes it down. The transfer, in order:

1. Inventory what the source provided. Deploy, secrets, a database, auth, logs. Each becomes a line in the new repository's README with who now provides it, or a trigger that is now true.
2. Write the spec the app never had. What it promises, its invariants, its boundaries. On a hosted platform the agent's chat history is the only record of intent, and it does not travel.
3. Find any second implementation. A companion that re-implements another system's rules (a visualizer that recomputes what a simulator computes, a client that re-derives a server's pricing) is a contract between two implementations with no test. Either share conformance fixtures between them, or make the companion replay the original's output so there is only one implementation.
4. Run the triggers against the target context, and plant the fault for each one that is true.
5. Move the credentials last. Bringing a credential into the target is a move in its own right (see the next section). In context 3 it becomes ambient; in context 4 it is injected by name.

Hosting platforms and clouds cover the generic rows: deploy, secrets, telemetry, and infrastructure fault injection (killing instances, adding latency). The re-trigger is covered too, once the app is deployed: managed SLOs with burn-rate alerts. None of them covers the rows that depend on what the app means: the contract, the invariants, faults in the app's own logic, and checks on the checks. A platform agent that "tests its own app" sits on the wrong side of the observable trigger: a model reviewing its own output, with no planted fault.

Most business software is not written from nothing. It is ported: a spreadsheet becomes an application, a manual process becomes a service, a codebase moves to another language or runtime. A port has something greenfield work never has, an existing system that is already right about most things, including things nobody wrote down. The hardening question for a port is what plays the oracle, and how to keep it from moving.

There are two starting points, and they need opposite first steps.

• One repository. Every failure above comes from one lab repository in one context. The three-tier rule for these notes asks for two repositories that agree; this note is ahead of that, and should be revised when the triggers are applied to a second project.
• Citations not yet audited. The references in What the literature says were written from memory, and the search budget ran out before they could be checked. Venues and years may be wrong; chapter numbers are left out on purpose.
• Context 4 is untested here. What a sandbox provides is inferred from how such harnesses are built; no run in this repository used one.
• The re-trigger is a design. No ledger has been kept yet.
• The transfer steps and the acting-on-the-world trigger are unearned. No app has been moved through them yet, and no order has gone wrong.
• The porting steps are drawn from practice reported elsewhere, not from a port done here.

• Live mutants: the contexts table and the four moments to stop and reflect that this note extends.