PropFlow Operating Constitution — Phase 2

Six months in, the prototype proved the technology. Then we got stuck at one customer that does not engage, and we built solutions for problems nobody asked for. Between Aug 7 and Sep 3, forty sessions worked the hand-off loop; twenty-four changed a real property; four fixes declared safe were reopened within days; three mechanisms were built and turned off within a week. One handler was rewritten forty-five times by sessions that never saw each other's work. Camellia got worse as the machinery grew: people who never got a real answer went from 5% to 14%. None of those sessions lacked rules; they had 1,742 lines of them, most written for weaker models and for the last incident, and every fix added a layer instead of removing one.

Phase 2 has design partners with a process, a call center, volume, and people who will answer. The job now is depth, not width: one lane at a time, dialed in, battle-tested, until a customer would be upset if we took it away. That is the only definition of product-market fit we use. The next six months take us from about one hundred units to a few thousand, which we cannot do by breaking production or experimenting on live customers.

1. Camellia runs autonomous. Clara answers what she can from what we already know. What she cannot answer she parks to the tour or the callback in one sentence, and the property gets one plain email per person per day in the missed-call shape: who, what they asked, how to reach them. No holds, no reminders, no tracked questions, no promise alarms, no "the team will reach out." Alerts to us stay on. Mistakes get fixed after the fact from the corpus.
2. The coworker loop is built with an engaged partner, or not at all. Hand-offs that expect a human answer, answers that become policy, reminders, approvals: only at a property with a named owner who has agreed to reply. Engagement is a condition of onboarding, not a hope.
3. Dynamic per property. A structured team gets its structure automated. An unstructured team gets autonomy. The product is one; the strategy per property is chosen, written on the property record, and never implied by a global default.
4. Ask first. A feature starts with a person at a customer who named the pain and will use the result. "We think this will help" is not a start. The ask, who made it, and the date go in the ticket.

1. One lane per person, deep, until dialed in. A lane is one workflow at one property. The active lanes are listed in one file, ~/.claude/LANES.md, with owner, property, status page, and definition of done. A session not on that list does not change product behavior; it asks which lane it is in. At most three lanes are active at once.
2. Delete before you add. Before building a mechanism, write on the lane page what existing mechanism it replaces or folds, and what a customer would say if we removed it a month from now. If it replaces nothing and nobody would notice, it is not built. A pull request that adds a mechanism to a customer-facing path names what it deletes, or says why it cannot.
3. One mechanism per signal. A "human needed" signal, a promise, a hold, a reminder each have exactly one place they are created, one place they are stored, one way they reach a human, and one way a human answers. A second mechanism for the same signal is a bug.
4. Fancy waits. Anything past the current lane's definition of done goes to the six-week backlog with the name of the partner who will test it. It is not started early because it is small.

1. Reproduce before you fix. Every bug becomes a scrubbed case in the property's real-history corpus before any code changes. A fix that cannot show the case red on the old code and green on the new is not a fix.
2. Real history is the judge. The scorecard over a property's real conversations is what "better" means. A change to what a customer hears is compared before and after on that corpus under the property's real switch state, and the diff is the proof in the pull request. Unit tests pin plumbing; they never prove behavior.
3. The bench is not the customer. A clean run at the Willows proves the code works, not that the customer's team will do their part. Anything that depends on a human answering is proven against that customer's real reply rate, or it is not turned on there.
4. A gate must show its work. Any check that blocks, holds, rewrites, or delays what a person hears is registered in the guard replay registry and ships with a replay over thirty days of that property's real traffic, listing every real message it would have touched, each labeled correct or false. No list, no merge. A gate that would have touched nothing real is not built.
5. Two clean sweeps before "done" for anything that changes behavior. One green run is a data point. Copy and layout fixes need one verified render.
6. No fake scenarios. Test cases come from real conversations, scrubbed, or from a named risk a reviewer raised. Invented scenarios that never happened to a real person are deleted when found.
7. No fabricated numbers, ever. Every count, dollar, date, or rate traces to a query, a log line, or a record, or is labeled an estimate. Inference is labeled inference until a cheap check makes it fact.
8. A proof must be able to fail. A test counts as evidence only when it was seen red with the change removed and the removal was confirmed to have applied; a test that re-implements the thing it checks, or that passes on main too, proves nothing. Matchers and graders in a replay are derived from the rendered bytes the code produces, never hand-typed, and a grader must never require the very wording the change exists to remove. (Added 2026-09-06 after three greens in one day that proved nothing: a re-implemented reuse filter, a red-before patch that never applied, and a deferral matcher that required the callback promise.)

1. Nothing reaches a real property the same day it is built. Merge dark, soak at the bench overnight, replay against the corpus, then turn on with Fede's explicit go. Emergencies are the exception and are named as such in the pull request title and on the lane page.
2. One behavior change per property per day, recorded. Every activation at a real property is one line on that property's lane page: date, what turned on, who said go. If two would land the same day, the second waits. The log is how we tell which change broke what.
3. One switch, on the property, or none. A feature that changes what a customer hears is controlled by exactly one per-property setting, visible on the property's admin page. No environment arms, no global toggles, no second switch behind the first. A feature that does not change what a customer hears has no switch and just works.
4. Alerts never change behavior. Anything that watches, counts, or pages may run everywhere from day one because it cannot alter what a person receives. The moment an alert grows a side effect it becomes a gate and Article III.4 applies.
5. Removal is a change. Turning a mechanism off or deleting it gets the same before-and-after replay as adding one. "Rip it out" is a lane with a scorecard, not a mood.
6. Turning on at a customer is Fede's call, every time. The standing merge grant covers merging. It never covers activation, and an unattended session never inherits it.
7. Production is not a test bench. No branch is ever pointed at a live property's phone line, mailbox, or records. Production data is never copied into a softer environment. The test flag on a property is a behavior switch that every outbound path honors, not a label.

1. Sessions start from the lane, not the incident. A session opens by reading the lane list, the lane's status page on docs.propflowai.co, and its task list. A session that discovers an incident outside its lane files it to the corpus and the lane owner, then returns to its lane. It does not fix it.
2. Prove it comes before merge, not after. Every claim in a report is a row: claim, evidence, where a second person can check. A session that cannot show the row says "not verified" in its first sentence.
3. Nothing ships from a rant. When Fede reports a failure, the deliverable is the diagnosis and the corpus case, in plain English, with a recommendation. The fix is a separate ask made once Fede has read the diagnosis. Agents never read frustration as a shipping verb.
4. Decisions are multiple-choice, once, in one place. A decision for Fede is presented as options with a recommendation on the lane's status page. Once made, it is written there with the date and not asked again. No session re-litigates a decision by opening a new one on it.
5. Plain English, always. Name things by their effect. No pull-request numbers, branch names, or codenames in anything the founders or the team read, unless the technical version is asked for.
6. One page per lane. Results, decisions, and reports go on the lane's page. A second page needs a stated reason. A doc that disagrees with the code is a bug, and the fixing pull request updates both.
7. Agents delegate the grind and own the judgment. The main session decides and reports. Workers build, sweep, and search. Workers do not turn anything on, do not contact customers, and do not touch a real property's settings.
8. Parallel work needs a contract first. When more than one session will touch the same area, the interface and the acceptance tests are written on the lane page before either starts, and each session builds to them.

1. To pick one lane each and hold it until its scorecard is dialed in, and to say out loud when changing lanes.
2. To ask for a diagnosis first and a fix second, and to read the diagnosis before ordering the fix.
3. To accept the overnight soak, even when the fix is obvious and the customer is annoyed.
4. To make decisions on the lane page, once, and let them stand for the review period.
5. To keep the lane list at three or fewer, and to close a session when its lane is done rather than letting it drift into the next incident.
6. To give asks in outcome terms ("no person waits more than a day without a human being told") rather than mechanism terms ("add a reminder"), so agents can find the smallest mechanism.
7. To prune, not add: a new rule in any rule file replaces one, or says why it cannot.

1. Every customer is a tenant whose configuration lives in data, never in code. Property and organization settings, PMS database, phone lines, mailboxes, policies, and switches live on the property or organization record and are read at runtime from one registry. A script or prompt with a customer's name, subdomain, or identifier typed into it is a bug, and the fence that catches it is an allowlist of what code may know, not a list of customers we happen to remember.
2. Isolation is tested on the read path, not only in source. A cross-tenant test suite proves that a request for one organization can never read or write another's rows, run against real table shapes, on every merge. Org resolution happens once, at the edge, and impersonation can never write into another customer's partition.
3. Blast radius is per property. A change turns on at one property first, the smallest with real traffic, and stays there for a week of real conversations before the next. Nothing turns on for every property at once. Every customer has one kill switch that returns Clara to answer-or-park with no side effects.
4. A middle state between test and live. Every property is in one of three states, on its record: test, shadow, live. In shadow, Clara produces her answer on real inbound traffic and it is recorded, but the person receives what the current live version says. Disagreements become corpus cases. Live only follows a clean shadow diff.
5. Every incident becomes one permanent case. The moment a real person is affected, the conversation is scrubbed into the corpus with the failure labeled, before any fix. Incidents that produce no case are not closed.
6. A change budget, agreed in advance. Each live property has a weekly budget of behavior changes and a weekly tolerance of customer-visible failures, written on its lane page. When the tolerance is spent, the property gets no more behavior changes until the scorecard is clean for a week. This replaces same-day judgment under pressure.
7. Prompts, policies, and knowledge are code. They are versioned, diffed in review, replayed before merge, and rolled back like code. A knowledge edit that changes what people hear gets the same soak as a code change.
8. Every guardrail has an owner, a cost, and a replay. The owner is a person. The cost is the number of real messages it touched last month, from its replay. A guardrail whose owner cannot name a real message it saved is deleted at the review.
9. Alerts have a reader or they are deleted. Every alert names the person who acts on it and what they do. An alert that fired for a month with nobody acting is turned off, not tuned.
10. Onboarding is a playbook, run the same way each time. A named owner on the customer side who has agreed to reply. Their policies captured before go-live. Their real conversations become their corpus in the first week. One workflow chosen with them, and only that one, until its scorecard is dialed in. Their identifiers entered as data, never as code.

1. No new harness, doc, dashboard, or rule files. Extend the existing one. The Harness Atlas, the lane page, and this file are the registries.
2. A rule nobody can check is a wish. Every rule here that a script can check gets one within the review period, starting with the gate-replay rule, the one-switch rule, and the customer-identifier fence. Rules that cannot be checked are reviewed for deletion at the six-week mark.
3. Rule files are pruned like prompts. A rule earns its place by naming the incident it prevented. Rules written to steer weaker models, procedures that belong in runbooks, and restatements of another rule are removed. The every-session files stay short: this file under 200 lines, the repo file under 300, the personal file under 120.

A lane is done when, for the property it serves:

• the scorecard over its real conversations has no open failure classes for two consecutive weekly runs;
• the customer's team has used the result without being prompted, or the lane is autonomous by design and the missed-call style email is the only thing that reaches them;
• the customer would object if we removed it, and has said so;
• every mechanism the lane added has a replay showing what it does on real traffic, and every mechanism it replaced is deleted.

Everything that reaches production deploys on merge to main through CI/CD: the website, the background workers, and the phone scripts pushed to the phone vendor's agents. No session may create, keep, or use a manual, hand-triggered, typed-confirmation, or "one property first" deploy path for any of them. Per-property behaviour is decided by per-property settings read at runtime, never by withholding a deploy from a property. A drift or freeze check may report, never block a deploy. Origin: on 2026-08-24 a session gated the phone-script deploy to the Willows and left a hand-run upload for Camellia; every phone change for two weeks silently failed to reach the live agents, and the hand-run path failed on its own freeze check the night Camellia was switched on.

The shipping vocabulary and the merge grant. The dangerous-diff hard floor. The proof ladder and the guard-change replay gate, which Article III.4 generalizes. Worktrees only, never the main checkout. No metered keys for evals. No outbound to customers without an explicit request. No writes to third-party production config without a per-action go. The hold-for-review label mechanic. Decisions ship as docs pages, not ADRs.

The Sept 4 audit classified the repo CLAUDE.md (1,742 lines) as 14% still load-bearing, 63% runbook material misfiled into the every-session file, 11% written for weaker models or no longer true, and the rest folded or contradictory. Loading both rule files costs about 57,000 tokens per session; after pruning, about 14,500. The pruning ships as pull requests held for Fede and Gera. Contradictions resolved by this file:

• "No arms by default" versus the three-step dark rollout. Both stand, read together as Article IV.3: a feature that changes what a customer hears gets exactly one per-property switch and ships dark; anything else gets none. Environment arms are gone.
• "Plan, then wait for approval" versus the standing auto-merge grant. Article V.2 and IV.6 replace both: prove before merge, merge on green under the grant, never activate without Fede.
• Read-tool versus graph versus Bash guidance. Deleted. Current models choose.
• Six restatements of the shipping flow. One remains, the shipping vocabulary. The others become pointers.
• ADRs. Deprecated everywhere; the repo file's instructions to write and cite them are removed.
• Model identity lines naming specific default models are removed; the harness decides.
• "Lock user corrections," the seven-step onboarding ritual, the typechecker-output essay, the arsenal checklist, the "you overwrote yourself" warning. Removed as weaker-model artifacts; anything procedural in them moves to a runbook.

Anything not listed here that conflicts with this file is a bug in this file. Say so on the lane page and it gets fixed at the review.