Fourteen days of standups and client calls in #transcripts, read against the decisions the fleet is still putting in front of Gera.
2026-09-13 · window 2026-08-29 → 2026-09-12 · source: Slack #transcripts (C0BE1NFTA0K), 79 posts, 19 meeting recaps, 7 raw transcripts opened
The hypothesis holds, and it is simpler than expected. The meeting recaps in #transcripts are good — accurate, detailed, and they already contain the answers. Nothing routes them anywhere. 151 tickets were filed from these meetings to per-person boards in this window, and not one of them reaches the phases board or the decisions surface, which is where the fleet actually looks. So the fleet asks. The largest open question in the portfolio-architecture work was settled out loud by the founders on Sep 2 — nine days before a lane took a "model decision under delegated authority" on it, believing nobody had ruled.
Gera's method, followed as given: read the summary at the top of each post; open the raw transcript in the thread only where the summary touched the product or the architecture. The window holds 79 channel posts — 19 machine-written meeting recaps (:memo:), their ticket-filing and fact-check siblings, and the daily WhatsApp mirrors. All 19 recaps were read in full. Seven threads were opened raw: Aug 31 (founders), Sep 2 (founders), Sep 9 (post-client debrief), Sep 10 (permissions), Sep 11 (vendors), and the Sep 11 and Sep 12 WhatsApp mirrors. The ~43,000-word Sep 1 operations deep-dive and the Aug 29–Sep 8 daily mirrors were deliberately not opened — see §5.
Raw transcripts were pulled through conversations.replies directly rather than slack-find --thread, which truncates every reply to 400 characters and would have silently dropped most of each transcript.
In property-manager English. Every row is a real decision spoken in a real meeting, with the date and a link to the post.
| Date | The decision, plainly | Source |
|---|---|---|
| Aug 31 | Stop building new screens for four weeks. Two people cannot onboard new buildings and polish the app at the same time. Critical bugs only; any new UI request goes on a list unless somebody funds another pair of hands. | standup |
| Aug 31 | We are not a single-building product any more. Everything in the system is currently attached to one building. A customer who runs one office for many buildings needs settings that live above the building — one phone line, one calendar, one rule book — and that is weeks of backend work, not a screen. | founders |
| Sep 1 | Throw out the assumptions. After a full day inside the first large customer's system, the read was that it is far bigger and far messier than anything we modelled — stale rent roll, data spread across the property system, spreadsheets and a whiteboard. "One week" became "a few months." | debrief |
| Sep 2 | We adapt to their software; they do not move to ours. We read and write inside the customer's existing property system by driving it like a person would, and mirror every message into PropFlow. Known cost: those adapters break when the vendor changes a screen. Accepted for the first customers. | founders |
| Sep 7 | The word is "org", and an org is the customer. One customer, one walled house. Buildings sit inside it. A person who works for two customers is one login with a switcher, never two accounts. | founders |
| Sep 10 | Build only the permissions the first customer needs. Rules live with whoever runs the building day to day, with a per-building override. Full enterprise permission tiers are deferred. The design must still fit all three shapes of customer so nothing has to be re-migrated. | standup |
| Sep 10 | Fewer features, fully finished. Explicit retro: piling on shallow features created a maintenance tax. From here, depth over count. | standup |
| Date | The decision, plainly | Source |
|---|---|---|
| Sep 2 | Maintenance line first, then leasing, then renewals. Rationale: the maintenance line only takes a request and writes it down, so it has the least to get wrong. | founders |
| Sep 4 | The customer pushed back on that order. Their operations lead said the real gaps are weekend leads going untouched until Monday and nobody answering the phone — not maintenance, which their existing call centre does route. | client call |
| Sep 9 | Order flipped: leasing first, then renewals, then maintenance. Leasing is the most dialled-in module and the client's biggest need. Each phase is built and tested with the client before it is switched on, so a break cannot take down the whole phone line. | onboarding standup |
| Sep 9 | Do not rebuild their phone system — forward to ours. Their existing number and menu stay exactly as they are and permanently forward to our line. This deliberately leaves their after-hours maintenance arrangement, which they pay for regardless, untouched. | onboarding standup |
| Sep 9 | Maintenance runs in shadow mode first. Record every call, create the work order inside PropFlow only, write nothing back to the customer's system until they approve. The recordings become the test set that proves quality before the switch is flipped — so there is no backfill and no arguing about whether it works. | debrief |
| Sep 3 | Stop pre-approving Clara's every move. The human-approval gate on the test property was blocking ordinary things — rescheduling a tour, filing a work order — and a fair-housing check misfired on a prospect who mentioned a dog breed. Decision: let Clara run, review afterwards. | founders |
| Date | The decision, plainly | Source |
|---|---|---|
| Sep 2 | Onboarding is a questionnaire with our answers already filled in. Roughly ten questions per module, pre-filled with what PropFlow recommends. Accept, skip or override. Skipping uses our standard. | founders |
| Sep 7 | The rent-roll drag-and-drop comes out of onboarding. Half-built and only partly wired. Rebuild it later if a customer without a property system ever shows up. | founders |
| Sep 7 | Sign in as Clara, not as a founder. Move the customer-system logins off personal accounts onto the agent's own account, and consider one email per customer so that if one account gets throttled it does not take the others down. | founders |
| Sep 10 | Terms are a checkbox, not a signature. Accepted during onboarding with the customer's legal name pre-filled, and the acceptance recorded. No contract exhibit up front. | standup · first raised Sep 3 |
| Sep 11 | Every module gets its own small onboarding. You pick your vendors, set your order, confirm your rules — and only then does that module switch on. "It wouldn't be automatic. Like, you have to set it up." | vendors call |
The Sep 11 call was called specifically to settle where vendors live. It reached four rulings.
| The ruling | In their words |
|---|---|
| A vendor is its own thing, not a thing owned by a building. One global vendor record; each customer keeps its own preferred list pointing at it, at the customer level or the building level as they choose. Duplicates are resolved on the global record. | "I'll just keep independent vendor cards, and then everybody has their own preference around that global set. And then if we have duplicates or anything, that's done at the independent vendor entity." |
| Ratings stay private to the customer. We are not building a public vendor rating service — Yelp and Google already are one. A bad experience may be one bad technician, not a bad company. | "I don't think we want to be like the, hey, public ratings… it should be private to the organization." |
| Your own maintenance staff are not vendors — even though the customer's property system lists them as vendors. Gera's first instinct was to import them anyway and hide them; Fede talked him out of it, and Gera landed on archiving them. | "Brian is not a vendor. Sure, it's set up that way, but… they added Brian just for, maybe, accounting purposes, so we don't want to copy-paste just because someone 5 years ago did that." |
| Stop syncing the whole vendor list. Pull it once so it is there, then have the customer pick their preferred few during the module's onboarding. The rest is a catalogue we do not maintain. | "That vendor list is just gonna be a catalog for our back pocket, but nothing we need to maintain. So yeah, I'll push that strategy then." |
Source for all four: Sep 11 vendors call, raw transcript in thread.
What we are still asking. portfolio-architecture-how §10, ruling D-0910-1, states the question as open:
OPEN — which settings may carry a default. Product behaviour, such as an agent contact window, is safe. A business term, such as a pet fee, is not… Proposed, not decided: business and legal terms carry no default and resolve to an explicit "I don't have that — finding out"; product behaviour may carry a default. The eligible key list and that boundary still need a ruling.
portfolio-architecture-how §10, D-0910-1
A board row, p00-build-defaults-layer, is gated on it. And the note that unblocked that row — docs/planning/portfolio-architecture/how/notes/platform-defaults-per-key-2026-09-10.md — opens by saying the ruling is not the founder's:
Model decision, 2026-09-10, under delegated authority. Not a founder ruling… It adopts the proposed split — product behaviour may carry a default; business and legal terms, anything a resident could rely on, may not… It is not the founder's ruling and a founder may reverse it.
The founders drew exactly that line, in conversation, on Sep 2. Sean proposes the pre-filled questionnaire; Fede stops him on the word:
Fede: When you say policy, are you mixing, like, settings with policies, like… late fees, or…
Sean: Well, I guess you're right — I'm thinking settings, I was thinking more like settings.
Fede: Application fees, sir.
Sean: Policies would be like, what fees do you charge.
Fede: Yeah — settings, basically… redo our settings page, and then have kind of like some defaults. They're turned on, and they can go tune it… but there's things like, autonomously send renewals — probably you don't want that on until you finish onboarding that module.
Founders' standup, 2026-09-02 — raw transcript in thread
That is the same split, named by the founders, with a safety rule the delegated note does not have: a behaviour that acts on the customer's behalf stays off until that module's onboarding is finished. And Gera had already set the confirmation requirement two days earlier:
Gera: Or we can just default them to, like, standard values, if they're okay with that… because there's so many edge cases. We wanna make sure that the portfolio level manager knows about everything and they've signed off.
Founders' standup, 2026-08-31
And Fede closed the loop on Sep 11, generalising it: every module gets a small onboarding where the customer confirms its values, "and only then we turn it on."
bug-imported-staff-indistinguishable-from-vendors is open on the board. The answer, and the reasoning behind it, is in the Sep 11 transcript in full — including Gera's own initial position and why he dropped it:
Gera: I'm still kind of leaning on, create the vendor card for Brian, because that folio has it, but we need to make it private.
Fede: I wouldn't, man… they added Brian just for, maybe, accounting purposes, so we don't want to copy-paste just because someone 5 years ago did that.
Gera: Oh, I see. So end goal is… not delete it, maybe archive it. So anyone that comes in and they say, oh, this person is a vendor, but they're really my handyman — okay, let me archive their vendor entity.
Vendors call, 2026-09-11
The failure mode Gera named is the one to design against: "we don't want property B saying, oh, Brian is in the area, let's call him." A staff member imported as a vendor becomes dispatchable at a building he does not work at.
This matters as much as the hits, because it says where the escalations are actually coming from.
| Block | What it asks | Answerable from a transcript? |
|---|---|---|
b89271767 | Add a Bash permission rule so a lane can remove its own hold-for-review label. | resolved — and it was never a product question. It is a permission on Gera's own machine. |
b89273365 | A PR is code-complete and pushed; the auto-merge guard is holding it. The PR is propflowai#8152, "ci: name the review-debounce decoy run so --limit 1 stops lying" — it touches a CI workflow, a runbook and a test. | No. Nothing about the product. A merge-policy question about our own robots, on a change to our own robots. |
Neither is a decision only Gera can make about the product. Both are decisions only Gera can make about the machinery, because the machinery is configured under his account. That is the real distribution. A scan of blocked outstanding shows the same skew across the older backlog: the overwhelming majority are "may I push", "may I merge", "this PR is green, do you want it live", "a lock is stuck" — questions answered by Gera's own CLAUDE.md ("push and drive to merge by default"), not by any meeting. The product questions are the rarer kind, and they are the ones the meetings keep answering.
What the design holds. HOW §10 ruling (3) and D-0910-1 and D-0910-5 together define an acting operator — a stand-in holding the login under a dated mandate until the real operator onboards, with a single handover mechanism for the handover and any later operator change. p00-operator-vocabulary makes acting operator permanent product vocabulary, glossed in the row itself as "the stand-in holding the login until the operator onboards (Yale: JP&Co)". The dates are tight and worth stating exactly: the acting-operator shape (b89000051) was raised 2026-09-09 19:27 CDT and answered 19:51. D-0910-1 (b89017673) was raised 2026-09-10 00:21 CDT and answered 00:35. The founders’ standup below began at 18:01 CDT the same day — about seventeen and a half hours after the ruling it talks down.
What the founders said the next evening, naming that exact case:
Sean: This hybrid access is not gonna exist in the real world… we're acting as the temporary custodian of the Yale account until we onboard ConAm. We don't need to be solving for that circumstance. It's not gonna really exist in reality.
Fede: I would just move what we have for Yale Station to a new org for ConAm. Dara be the admin. Instead of… all the fancy permissions and hierarchies. We're building this like an enterprise solution that we don't need yet.
Fede: It's good that we've thought about it, but now let's be like, okay, what do we actually need this week, and just ship that. And then as we grow and scale, the company will have those bones we can add. Because you don't wanna be too enterprise to do quickly.
Founders' standup, 2026-09-10 18:01 CDT — raw transcript in thread
How much of this is a real contradiction. Honestly: the first half of the design agrees with them. D-0910-1's "mint the operator's house now, put the building inside it" is almost word-for-word Fede's "move Yale to a new org for ConAm, Dara be the admin." The contradiction is in the second half — the dated mandate, the stand-in attribution, the single named handover mechanism, the vocabulary that makes acting operator a permanent term, and the eight stress cases the page itself flags as unreconciled. That is the apparatus for a circumstance three founders agreed will not exist once Yale moves.
What to do with it, not for me to decide: either the Sep 10 standup is the later ruling and the acting-operator machinery collapses to "create the org, name the admin, move on" — or Gera holds that the machinery is cheap insurance for the next customer handover, in which case the page should say so and cite the standup it is overriding. What it should not do is carry the mechanism as settled while the record shows the founders talking it down.
p8-sync is open, owned by Gera, added 2026-09-08, and its premise is that the full vendor sync should run per-org on every pass. Three days later Gera himself raised the consequence and both founders agreed to stop:
Gera: I created, like, a vendor sync, so every week or every day it would pull the vendors and refresh. One downside I'm seeing — if two orgs have different vendors, but there's gonna be some overlap if they're both in Denver… every day we're gonna have to be deduping… if they already have their 5 preferred vendors, the other 90-plus percent, it's just data we're maintaining.
Fede: Maybe we don't need to be syncing the entire vendor lists… we can pull the list, but then you have to select or import your preferred vendors.
Gera: That vendor list is just gonna be a catalog for our back pocket, but nothing we need to maintain.
Vendors call, 2026-09-11
The defect in the row is still real — a second org sharing one property-system connection currently gets no vendors at all, and that is a bug under either design. But the fix the row implies (make the recurring full sync run for every org) is the thing the founders decided to retire. The shape the meeting asks for is: pull once, let the customer pick their preferred few during the maintenance module's onboarding, stop maintaining the rest. Worth re-writing the row before anyone builds the version of it that is written down.
Phase 8 has p8-pickvendor — "pickVendor replaces the four dispatch call sites… auto-assign, the turnover walk and the roster half of the available-vendors tool become one function." Consolidating four call sites into one is good regardless. But the behaviour at the end of it was talked down in the same call:
Fede: You're dispatching — an AI agent wouldn't dispatch a vendor directly. Right? In real life. You get work orders and your maintenance team works there. And then they're like, hey, actually we need this specialized vendor because it's too hard. Then they raise their hand and ask the property manager to approve that. I don't think anytime soon Clara would be like, I get a phone call about a broken lid, let me call the HVAC directly, without going through the maintenance team first.
Vendors call, 2026-09-11
This is consistent with the Sep 6 standup ("dispatching deferred") and it says the in-house-first path is the product, not a fallback. Note the shape it implies, which is the reverse of Gera's stated mental model in the same call ("we only have vendor entities, but we have preferred, and our first preferred is our handyman"): staff are users and get asked first; vendors are entities and are only reached with a human's approval.
It is kept as a heading rather than deleted because the correction is the useful part: the recaps in this channel survived the one adversarial check this page ran on them. That materially changes §4 — the problem is not that the summaries are unreliable.
This is the root cause, and it is a plumbing problem rather than a comprehension one. The nineteen recaps in this window are accurate and detailed; the one place this page went looking for a flattened decision, the recap turned out to be right (§3.4). The answers exist, in a channel every session can read, in a searchable local index.
What does not exist is a route from a meeting into the surfaces the fleet consults. The :ticket: posts show 151 tickets filed from these meetings across 17 posts, into per-person boards. The phases board, the decisions surface and the architecture pages are fed by lanes, not by meetings. So a lane reaching a genuine fork — "which settings may carry a default" — grepped its own planning notes, found nothing, and correctly concluded the record was silent. The record was silent. The standup was not.
The specific gap is cheap to close and needs no new system: when a recap contains a decision that changes how something is built, the decision belongs on the decisions surface with its permalink, the same evening. Until then, the fleet's honest position is that an unrecorded founder ruling does not exist — which is the right engineering instinct and the wrong outcome.
The architecture work is paced against a go-live that the founders pushed on Sep 11 — set-up next week, an extra week of testing, switch-on only after the customer's phone migration. And the customer is 234 residential units, confirmed Sep 12, not the several hundred more the early standups sized. The design pressure that produced "ship the minimal version, defer the enterprise tiers" is, if anything, lower now than when that call was made. A page that dates its phases should re-read the mirror before it dates them again.
Three separate decisions are the same decision: adapt to the customer's property system rather than move them (Sep 2); forward their phone tree rather than rebuild it (Sep 9); pull the vendor list as a catalogue rather than own it (Sep 11). Fede's line is the whole thesis: "they have their PMS, but they have their scratch pad or their Google Doc. That's just human nature." The customer's system stays the source of record and PropFlow is the layer on top. Every design that makes PropFlow the authority on something the customer already maintains elsewhere is swimming against this, and the meetings will keep pulling it back.
Recurring, and under-represented in the architecture docs: a call at 2am that is a fire, or a person who is not a resident, or a call routed to the wrong building by a human call centre. Gera asked for an alerting path that reaches him directly before any of this goes live (Aug 31). The Sep 9 onboarding call deliberately deferred emergency handling. Both are true, and the gap between them is a real product hole with a date on it.
Roughly ten thousand real conversations were pulled from the first large customer's system and used to measure Clara against reality (Sep 2). Their call centre duplicates about 30% of its tickets and sets urgency on none of them (Sep 3). Recorded calls become replayable tests (Sep 9). The founders have a real-data quality strategy and it is barely visible in the engineering surfaces, which still lean on synthetic fixtures. Fede's phrase for the target is worth keeping: the bar is a ChatGPT-quality voice agent, not the call centre we are replacing.
An earlier draft of this section claimed the backlog is overwhelmingly machinery. That is wrong, and the real number is more interesting. Classifying all 173 rows in blocked outstanding by whether the text is about our own tooling (pushes, merges, labels, CI, locks, sessions, deploys) or about the product:
| Shape | Rows | Share |
|---|---|---|
| Our own machinery — "may I push", "may I merge this green PR", a stuck lock, a red main | 95 | 55% |
| The product — pricing, policy, copy, what Clara should say, which clock a quiet-hours rule uses | 78 | 45% |
Crude keyword classifier; it counts a PR number as machinery even inside a product question, so the machinery share is if anything overstated. Both halves are large.
Both halves have a different fix, and conflating them is why the volume reads as one problem. The machinery half is answered by Gera’s own CLAUDE.md — "push and drive to merge by default" — and by giving lanes the permissions they keep asking for one at a time; tonight’s two open blocks are both of this kind. The product half is the half this page is about, and spot-checking it against the transcripts finds more of the same pattern as §2:
b88363231, raised Sep 2 10:33 — "Pricing basis for Situs Group: per-workload vs per-unit". The per-unit-per-module basis and the phased intro discount were settled by the founders on Aug 31, two days earlier. Figures withheld here.b88890111, raised Sep 8 12:55 — "22 questions — phone numbers: one per building? whose calendar…". For the customer actually being onboarded, both were already answered: one shared line for the whole portfolio (Sep 9, and the forwarding decision with it) and one calendar for the portfolio despite two leasing people (Sep 7).b88913132, raised Sep 8 19:18 — "When one company owns a building and another manages it, who gets to set…". Answered in the Sep 10 standup: rules live with whoever runs the building day to day, with a per-building override, and the owner-side users get read-only visibility.All three were raised and answered by Gera — they sit in the "answered, no execution recorded" list, not the open one. That is the cost being measured here: not a wrong answer, but a round-trip that the record could have saved.
#agent-smith (C0BDW7G1Z62). Readable, and deliberately skipped. HOW §10 cites five decisions made there on Sep 7 — texting on the leasing line, leasing-only scope, the parallel fan-out build, the test line purchase, pre-approved number purchases. They are cited but not verified here, because the brief scoped this to #transcripts. Reachable with the same bot token: conversations.history --channel C0BDW7G1Z62.tickets-bugs, module-maintenance, module-onboarding and the per-property channels. The :ticket: posts in #transcripts show 151 standup tickets filed to per-person boards across 17 posts in this window; none of that traffic reaches the phases board or the decisions surface, which is itself an intuition gap I could not size.slack-find's keyword search covers channel-level text and thread replies, but its --thread printer truncates every reply to 400 characters. Raw transcripts here were pulled directly through conversations.replies instead. No rate limiting was hit; every fetch returned ok:true.Slack #transcripts (C0BE1NFTA0K), 2026-08-29 → 2026-09-12 · artifacts/portfolio-architecture-how.html §10, §12 · artifacts/portfolio-architecture-phases.html (159/295 rows done, 130 open at time of writing) · docs/planning/portfolio-architecture/how/notes/platform-defaults-per-key-2026-09-10.md on propflowai@main · blocked check and blocked outstanding, 2026-09-13.