Pick an option on each card and press Done; your answer goes straight
back to the session. The raiser's pick is marked. "I'm not sure" and "Take it to the engineering bridge" are real answers.
1When a prospect gives their name to book a tour Clara offered, should it count as booked once it's saved, or only once the calendar invite goes out?
In plain terms. Today the system saves the tour as confirmed and tells your team, then sends the calendar invite. If the invite fails, a background job retries it later. The tie-breaker split on this, so it needs you.
Why, and what was tried
The session raising this recommends: Booked once saved (retry job fixes a missed invite) It matches how every other booking path already works, keeps the fix small, and an existing job already repairs missed invites; the stricter option needs an extra ~200-line change to undo a confirmation. Tried first, unsuccessfully: fable-decide split under order reversal (receipt f5bc21c38): as-given NARROW high, reversed STRICT high; prior rulings f0bb095d9, fdb13a650. PR #19911 held at 477ca6c4dcc.
1fdb267c is parked on this.
Answered and withdrawn (130)
b89271767 A fix for a real bug in how we decide a pull request is safe to merge is finished, checked, and approved — but it is stuck behind a safety flag that this machine will not let me take off, and it will stay stuck until you either take the flag off yourself or let me do it. Letting me do it means I can also finish the nine other pieces of work running right now without stopping to ask you again; leaving it means each one waits for you. — answered: Gera adds a Bash permission rule allowing 'gh pr edit --remove-label', so this and every future lane can release its own hold
b89273365 A finished fix is ready but our own safety rule says a person has to press the merge button on it, because it edits one of the build files we deliberately never let a machine change on its own. Fede is the one who has read that file. Either he merges it, or you tell me this class of change no longer needs a person — leaving it means the fix sits there indefinitely. — answered: No decision is needed — the block's premise is stale
b89278033 Before we can build the settings registry, you need to sign off which settings count as a 'class' — the design says you personally sign that list, and warns that getting a single one wrong reverses a call you made on September 1st. Nothing is being built on it right now, so the choice is whether I have someone prepare the candidate list from the code this week for you to sign, or we leave it until closer to the October deadline and accept that one piece of work stays parked until then. — folded into b89415447
b89279042 On September 10th we recorded a decision to build the 'acting operator / handover' machinery — someone standing in for an owner, with dated mandates and a handover step. Eighteen hours later, on the same day's standup, you, Sean and Fede all talked that situation down: Sean said we don't need to solve for it because it won't really exist, and Fede said we're building an enterprise solution we don't need yet. Half that design is still in the plan and someone could start building it this week. Does it stand, or does it collapse to just creating the org, naming the admin, and moving on? — answered: ▎ Neither option as written. The vocabulary simplification stands — collapsing to Operator and Staff ▎ with no third role is what the standup was agreeing with, not overruling, so there's nothing to drop ▎ there. ▎ ▎ What goes is the ceremony: drop ADMIN_HANDOFF, ST-900 and the dated-mandate record. Replace them with ▎ — several parties can hold the operator grant, any of them revocable at any time, and every grant ▎ carries an expiry so it lapses on its own rather than waiting for someone to remember to remove it. ▎ That keeps the reversibility the mandate was built for without building the enterprise machinery Sean ▎ and Fede were right to talk down. ▎ ▎ Revisit only if a real customer actually needs a handover. Half two — the ceremony. A dated mandate carrying operator org, administering company, acceptance evidence, exact named buildings, start, expiry, revision; plus ADMIN_HANDOFF; plus an ST-900 completion contract with lineage revocation. That is what Sean and Fede were talking down. And notably, D-0910-1 already tells you to reuse what exists: "Retain the existing human administrator permission machinery… do not introduce a company role or an unrestricted org_admin shortcut" and "vocabulary corrections to one relationship, not another relationship alongside it." Your version, and the hole in it "Several operators, revoke later" keeps the thing the ceremony was built to deliver — more than one party can act, and it's reversible — and gets it from a primitive you already have (grants) instead of a new protocol. That's why it's stronger than option A: option A drops reversibility along with the ceremony. The hole: "revoke later" is a remembered end, not a derived one. Your own recurring rule is if a fact has to be REMEMBERED to stay true, it will be false. An operator grant with no expiry stays live until somebody thinks to remove it — and nobody will, because nothing surfaces it. That's how you end up w
b89329881 Should the system start using our new vendor records the moment we save them, or keep working the old way for a few days while we check they are right? Using them immediately is faster, but one wrong record sends real work to the wrong vendor. — answered: Store and read the real rows in one step
b89329895 Should each vendor we save carry a note saying whether a person actually approved them? Some were guessed automatically from old emails, so without that note a guess looks exactly like a vendor you approved and could be sent real work. — answered: Each saved vendor carries whether a human confirmed it
b89329919 Should an accounting user be able to change records, or only look at them? Two of our own documents disagree. If we make them read-only and that is wrong, they ask us and we widen it; if we let them write and that is wrong, they have already changed something before anyone notices. — answered: Accounting is read-only — add it to the tier list
b89337053 When one company stops managing a building, do we mark that record as ended and keep it where it is, or delete it and file a copy in a history area? Our design notes only ever describe marking it ended; the delete-and-file approach is something we do for attachments and never wrote down for this. A helper wrote the marking version, then stopped and asked rather than let its own choice become the answer. — answered: An endedAt attribute, set in place - confirm the lane's reading
b89340267 When every building has its own email address, what should happen to mail sent to our old shared address? Right now we guess which property it is from the subject line, which can put a resident's message on the wrong building. We could refuse it and tell people the right address, keep it only for bulk files like rent rolls, or leave it alone. — answered: Keep it as it is - the subject-line guess stays as the fallback for the shared address
b89340744 The switch that turns the new system on for one phone number at a time is finished and sitting empty, because nobody ever decided which number goes first. We own two test numbers that carry no customer traffic. Do we turn one of them on tonight and pause new building until it proves out, keep building while we watch it, or skip the test and pick a real customer's number? — answered: A bought test line - +18442853526 or +17208071724 - flipped tonight, and nothing new opens in Phase 7 or 8 until it has production evidence
b89343972 Turning the new front door on for real customers has been waiting for a yes that nobody ever actually asked anyone for. It is Fede's to give. The question is whether he gives it now, or waits until we have flipped one of our own test phone numbers and watched it behave. — answered: Fede gives the go now - promote to production and run the three exit checks
b89352028 The shared phone agent that will answer every line cannot yet look up available units or book, move, or cancel tours; only the Western Slope prototype can. Giving it those four abilities now puts them on every line it answers; gating them behind the same per-address switch we use for the cutover means the test line gets them first and nobody else until you flip them; waiting means the shared agent stays booking-blind until the test line has production evidence. This is Gera's call per the plan, shared with Fede where a real customer's callers would notice. — answered: C: Bind the four tools to the shared agent DARK, gated by the address-flip seam (config/flipped-addresses.json) so only flipped addresses see them; the test line gets them first automatically and the prototype's DISARMED kill switch pattern carries over
b89353873 For Gera AND Fede: which agent does 'the shared agent gets tools' mean, and is the row already met? Gera's answer tonight (bind the four tools to the shared agent, dark, so only flipped lines see them) rested on a sentence that turned out to be false: the shared leasing agent ALREADY carries all four abilities - look up the homes for rent, and book, move or cancel a tour - on every line it answers, Camellia included, and has for months; the file the question pointed at is only the wording the agent speaks, not what it can do. So 'only flipped lines see them' cannot be built without taking booking away from Camellia today. What IS missing, verified in the code: on a line flipped onto the new architecture, the START of the call already knows it answers for a whole company and names the company's homes, but the mid-call lookup still reads the one building behind the number - so that agent would open by naming fourteen homes and then tell the caller none are available. The design record says the agent that 'gets tools' is the single front-door agent that today has no tools at all, and that expanding its tools is Fede's product call - a different agent from the leasing one that already has them. Nothing is flipped yet (the test line waits on the address-collision cleanup), so any build is dark on merge either way. Three readings, pick one. — answered: Mark this done — the agent already has the booking abilities, so nothing to build there. Open a new row for the actual gap: per-phone-number feature switches under property settings. A number can serve more than one property (e.g. A and B share a number, C has its own), so the switch keys on the phone number, with the properties it serves shown for context. Under each number: on/off toggles for the agent's features (book / reschedule / cancel tours, unit lookup, leasing). Default off until validated, with a kill switch. Visible to operators and admins. This is a settings feature, so it waits on Fede's settings-registry refactor (or his explicit go) before it's built — don't build it ahead of that and get it reverted. — Gera and fede
b89369345 At 12:05am Clara offered Gera tour times and then refused to book because 'the office is closed'. The cause is a few missing sentences in the shared after-hours instruction, not the phone-line switch. Adding them lets Clara book tours at any hour on every line, including Camellia's; scoping it to the test line leaves Camellia's midnight callers with a note nobody follows up; leaving it means the contradiction stays. — answered: A: Ship the prompt fix tonight for every fleet — booking after hours was always allowed by the calendar and the booking policy; the prompt merely forgot to say so; Camellia's after-hours callers get a booking instead of a dead-end note
b89373143 Do you want the new 'pick several buildings' box to ship with the app remembering your building choice in ONE place, keep the old and new memory side by side just this once, or park the building picker and close this item on the company switcher alone? One place means each person's buildings come from their role records instead of the old hand-assigned list; on the test system that only trims admins and gives a few dummy accounts buildings, and I would read-check the live system before shipping. — answered: Park the building picker: close this item on the company switcher alone
b89381610 When a property manager says a vendor's name out loud on a call ("get Miracle Method to refinish the tub"), the system looks that name up against a list of the company's vendors — and that lookup is the last one still outside the new vendor-picking switch we have been moving everything behind. Putting it behind the switch changes nothing anyone sees today, but it means the spoken name and the automatic picker will always agree on which vendors a company is allowed to call; leaving it out means the spoken name keeps reading the old list, and could line up a vendor the company has stopped working with. — withdrawn
b89390774 The nightly maintenance test has been red two nights running (13 of 21 pass) because the test handyman's phone number now belongs to a real customer too, and Clara's text routing picks the newest match rather than the property that was texted — should we fix the routing so texts are matched within the property's own company (the way phone calls already are), or change the test setup so the number is only known to the test company? — answered: Scope text routing to the texted property's company (like calls)
b89391233 The AI write-ups about buildings were being stored in one shared place that every company's dashboard read from, and 221 of them were put there by someone using the product rather than by our nightly job, going back to March. Three fixes are written that stop any new ones and stop anyone being shown them, but those 221 rows stay in the live database until a person says what to do with them. Leaving them means they sit there unreadable once the fixes ship; moving or deleting them is a change to live customer data, which is why it is your call and not mine. — answered: Quarantine them after the fixes merge — move them out of the served partition without deleting, so nothing is lost and nothing is served
b89400852 The nightly job that builds your portfolio write-ups is running May's code, not today's.
Tonight we closed a hole where one company's building numbers could be shown to another company. We fixed it in four places and I checked every one in the live code. One of those four was the nightly job that GENERATES the write-ups. That fix is merged. It is not running.
The copy in production was last updated on 13 May. The fix landed today. A May copy cannot contain a September change. Its daily timer is still on, set for 05:00 UTC.
So at the next 05:00 UTC the old code runs again and writes one more company-crossing rollup into the shared place. Tonight's cleanup moved the 221 old ones out, and I checked that afterwards with my own separate queries rather than trusting the tool that moved them. Tomorrow's run puts a fresh one back. One row a day, not a flood - and nobody is being SHOWN it, because the reading side is fixed and live. But the tap is still open.
Why nobody caught this: merging this job never deploys it. A person deploys it by running a script by hand. There is no automation, so there was never a moment where anything could have said "merged but not live". That is the part worth fixing properly later.
I am not touching it on my own. Pushing code to production, or switching off a production timer, is exactly what I hold for you. I asked the decider and it said this one is yours.
A - Deploy it now. The job updates, and the next run writes properly scoped rows. Fixes it at the source.
B - Leave the code alone, switch the daily timer off. Nothing new is written until you deploy properly.
C - Leave both. One more row lands, we sweep it with the others, you deploy in the morning.
I recommend A, and I want to be straight that my first instinct was B and I think that was wrong. B stops one row a day by stopping the write-ups from being generated at all - that is a real feature switched off to fix something no customer can currently see. That is a bad trade. C is genuinely fine if you would rather do the deploy yourself with your eyes on it; the only cost is one more row on a pile we already know how to clear. A is the one that actually ends it. — answered: A - Deploy the fixed job to production now, then verify it updated and writes scoped rows
b89403444 The wall that stops one company seeing another's buildings is built, tested and switched off. The condition you set for switching it on is now met.
It is one environment variable, PROPFLOW_ROSTER_GATE. It has three positions, not two:
off (today) - it does not even look.
observe - it looks, and writes a log line every time someone reaches for a building they should not have, but lets them through.
refuse (1) - it returns the same "no such building" answer a genuinely missing building returns, so a stranger cannot even confirm the building exists.
You set the condition yourself: it arms only when no building in production is missing its company. I re-counted that tonight rather than trusting the note from two days ago: 82 buildings, zero missing a company. The condition holds.
This is the wall you already ruled came first - ahead of the signed partner's renewals. The plan's own review note is blunt about the halfway house: "an observe-mode gate is an instrument, not a wall."
Why it is yours and not mine: flipping it is a production configuration change that starts refusing live reads the moment it lands. I do not press those.
What the model reviewer said, and I want to be straight about how much weight that carries: it recommended refusing now. But it was ONE model, not two. The tool printed "Fable and Astra agreed independently" and that was false - Fable was never asked. What actually happened is that the one model was run twice with the options in a different order and agreed with itself. That is a real check against it just picking the first thing it read, but it is one opinion, not two. I am telling you because I nearly reported it as two.
And its own warning, which I think is the sharpest thing on the page: my count of 82 proves every building HAS a company, not that it has the RIGHT one. If any building carries the wrong company, refusing turns a legitimate view into a "not found" for a real person.
Three ways to go:
A - Refuse now. The wall is up tonight. If a building carries a wrong company, someone loses access until we fix it.
B - Observe first. It starts logging every cross-company reach without blocking anyone, so we see whether any legitimate read would have been refused before we refuse it. Costs a day, buys certainty. Nobody is protected yet.
C - Leave it off and keep refusing building-by-building through the ramp list, arming fully when you are watching.
I would pick B, and it is a close call with A. The reason is not caution for its own sake: the one thing my measurement cannot tell you is whether a building's company is CORRECT, and observe mode answers exactly that question in a day, by name, without anyone losing access. A is right if you would rather be protected tonight and fix any wrong building as it surfaces. — answered: A - Refuse now: set PROPFLOW_ROSTER_GATE=1, the wall is up tonight
b89404898 You decided weeks ago that anyone holding the keys to a customer's account should have those keys expire on their own, instead of someone remembering to take them away. Nobody had built it. Half of it is now live and the other half is one approval away — but building it surfaced two things your sentence does not settle, and I would rather ask than guess.
Your words were: "several parties can hold the operator grant, any of them revocable at any time, and every grant carries an expiry so it lapses on its own rather than waiting for someone to remember to remove it."
QUESTION 1 — does "every grant" include the customer's OWN administrator?
Taken literally, it does. But there is a real difference between the two cases:
- An OUTSIDE party temporarily administering someone's account. This is the case you were solving. If that access quietly lapses after 90 days, that is exactly right — it is the whole point.
- The CUSTOMER'S OWN administrator, the person who runs their company day to day through PropFlow. If their access expires on a timer, then every 90 days a paying customer's own admin gets locked out of their own account until somebody renews it. That is a different product experience, and I do not think it is what you were picturing when you wrote the sentence.
The lane building this took you literally and marked it "pending his word" rather than deciding for you. I think that was right.
QUESTION 2 — 90 days, or a different number?
The build needs a default lifetime and 90 days is what it proposes. I want to be straight: THAT NUMBER HAS NO BASIS IN ANYTHING YOU OR THE RECORD HAS SAID. It is a reasonable-sounding guess. If a third party is typically administering an account for a few weeks, 90 days is too generous to be much of a control. If they are on for a year, 90 days means four renewals and four chances to be locked out mid-engagement.
What is already built so a lapse is not a trap: how much life a grant has left is DERIVED and readable at any time, never a reminder someone has to notice; renewing is an ordinary action any current holder can take; and if an organisation somehow reaches zero live grants, one command restores it. The buildings keep answering the phone either way — none of that depends on a grant.
My recommendation: expire OUTSIDE parties only, and leave the customer's own administrator alone. That keeps the whole point of your ruling — access that somebody else holds over a customer's account ends on its own — without a paying customer's own admin being logged out on a timer. If you want it to mean literally every grant, say so and it is a one-line change, but then 90 days is probably too short.
On the number: I would rather you pick it than inherit my guess. If you have no strong view, 90 days is fine as a starting point and it is one constant to change later. — answered: Outside parties only — a customer's own administrator never expires; keep the default at 90 days
b89408774 Your answer this morning caught a real mistake before it shipped, and fixing it has exposed one more gap I would rather ask about than guess.
WHAT YOUR ANSWER CAUGHT. You said expiry applies to outside parties only, never to a customer's own administrator. The rule as built could not tell those two apart — an outside company and the customer's own admin hold exactly the same kind of access, at exactly the same level. So the code would have put a 90-day clock on the customer's own administrator: the precise opposite of what you just protected. That is now fixed by telling them apart a different way — an outside party is someone holding admin access over a company they are not a member of.
THE GAP THAT FIX OPENS, and it is not hypothetical. What about an outside operator who is ALSO given a membership in the customer's company? Under the new rule they read as "the customer's own administrator", so their access would never expire. That is a way around the rule you just set, and our own invite flow permits creating exactly that situation.
Three honest readings, and your sentence picks none of them:
A. TAKEN IN-HOUSE IS REAL. If you give someone a membership in your company, they are your staff now, and staff access does not expire. Simple, matches how people actually think, and means the expiry can be sidestepped by issuing a membership — deliberately or by accident.
B. REMEMBER HOW THEY ARRIVED. Record whether a person was invited as an outside party, and keep expiring them on that basis even if they later gain a membership. Closes the gap. Costs a new piece of state that has to stay accurate, and your own rule is that a fact which must be remembered will eventually be false.
C. ATTACH THE CLOCK TO THE ARRANGEMENT, NOT THE PERSON. The expiry belongs to "company X is administering company Y", so anyone acting under that arrangement expires with it regardless of memberships. Cleanest conceptually. It leans on a piece of the design whose survival is explicitly still undecided, so it may be building on something that moves.
I recommend A, and I want to be straight that it is the weakest against the bypass. It is the only one that needs no new remembered state and no undecided design, and "we gave them a membership in our company" is a deliberate act by someone on your side, not something that happens quietly. B is right if you expect outside operators to be given memberships routinely and want the clock to survive that. C is right if you would rather the whole arrangement expire as one thing, but it should wait until the piece it depends on is settled.
Nothing is blocked on this. The rest of the work stands under your literal answer either way, and the code ships correct for every case except this one. — answered: C - Attach the clock to the arrangement, so anyone acting under 'X administers Y' expires with it regardless of memberships
b89411968 AppFolio is refusing us because one report still asks about every building one at a time instead of asking once. The efficient version is already built and switched on for seven other reports — this one just never got switched on, on two of your accounts. Flipping it is a change to live customer settings, and the safety net everyone assumed exists (a practice account) turns out not to be real, so this needs a person. I did not flip it. — answered: A: You press both now — set-unit-vacancy-portfolio-arm --on --apply for appfolio#jpco#5cd0 and appfolio#westernslopepm#17a5. Fixes the measured 74-of-99 refusals tonight.
b89412009 Some dashboard numbers are averages, and there is no honest way to combine an average across several buildings unless we say what to weight it by — a 200-unit building should not count the same as a 6-unit one. Right now those tiles just come back empty. I would rather they say "can't be combined across the buildings you picked" than either stay blank or show a made-up number, but picking the weighting is a business call. — answered: C: Do not average across buildings at all — the tile says "not computable across the selected set" and stays honest, costing 49 tiles under a multi-building selection
b89412274 Should lane 003 build the company-level knowledge read for Clara's phone calls now, or wait for Gera? Today Clara only reads each building's own facts, never the company's. Western Slope's company rules (screening, fees, pets, contact) work on the phone only because they sit on the stand-in front-door building. Moving them up to the company before Clara can read company facts would silence those answers on a live line. The read plumbing is the first step, changes nothing callers hear on its own, and sits next to the anchor retirement the design already assigned to Gera. Nothing moves and nothing goes live until this is answered. — withdrawn
b89415447 Every setting in the system has been sorted into one of four kinds - and a model did that sorting on your behalf, not you. Nothing is wrong with it as far as anyone can tell, but the plan says you have to be the one to sign it off, and no customer has entered any settings yet, so today changing your mind about any of them is free. Once customers start entering values, moving one the restrictive way costs about half a day each - using a tool nobody has built yet. Signing it as-is changes nothing and lets two stuck pieces of work move. — answered: A: Sign it as written - I read the list, it looks right, ratify all 61 keys. Changes no code; unblocks p3-registry and p4-escalation-key immediately
b89417046 The code reviewer bot is nearly out of capacity until Thursday: 8 of our 11 reviewer accounts have hit their weekly limit (resets Sep 18, 1am UTC), a 9th hit its 5-hour limit, and one of the two accounts still working is at 96% of its week. When those two run out, every PR review across the company will fail until the reset. Should we add reviewer seats now, or accept review outages until Sep 18? — answered: Well currently our current account has seats, so just make them continue. You'd have to just nudge them if they're stuck. Like just tell them to continue despite their message and they will continue. (Gera, in chat, 2026-09-14 ~21:35Z; not one of the offered options -- neither 'add seats' nor 'accept outages': the seats already exist, the cap is a message the accounts will continue past when nudged)
b89430905 The account my helpers run on has used up its whole week's allowance, so every helper stopped and none can start again until next Saturday evening. Telling them to keep going does not work because the account's pay-for-extra setting is switched off. Either you switch that on and pay for the extra, or you move me onto one of your other accounts and I carry on tonight, or everything waits five days. — answered: no they are good, just nudge them to continue (Gera, in chat, 2026-09-14 ~22:15Z -- not one of the offered options: the seats are fine as they are; do not flip overage, do not rotate; resume every dead lane by telling it to continue)
b89431875 Two different pieces of work both tried to define what a PropFlow staff member sees when they pick 'all companies', and they contradict each other. The one already live is the simpler one and is what your staff logins use right now. I recommend keeping that and re-doing the useful bits of the other on top of it, rather than tearing out what is live. Either way, nothing merges on this until you pick. — answered: A: FLEET WINS. Close #8403 as superseded; re-cut its still-valuable parts (one staff test at resolveGrantsFor; the shared isCustomerOrganization predicate; the short-circuit deletion ONLY where the aid's ADR-0135 keeps the admin-page gate) as a NEW part 2 on top of fleet.
b89439307 A real customer's personal email address was accidentally put in a test file, was caught and removed before it reached our main code, but GitHub keeps the old draft versions retrievable to anyone with access unless we ask GitHub Support to delete them — do you want us to ask? Asking is one support ticket and the address is gone for good; not asking leaves it findable by anyone who can see our private code. — answered: No, leave it; it never reached the live code
b89439534 Should a customer's vendor engagement be a normal relationship record, or keep its own separate shape? Background: an engagement is the record that a customer has agreed to work with a vendor. It is stored under a key that looks like a relationship but is not in the relationship registry, because its shape carries no partner and no start date. Normal relationships end by being marked ended in place. The vendor design instead ends an engagement by moving it into history while keeping the uniqueness guard. Tonight we built that ending exactly as the vendor design specifies, switched off, touching no data. Registering the engagement as a relationship waits on your choice. — withdrawn
b89516651 Should Clara actually use the thing we now work out on every call — whether it's about one specific home or the whole company? Right now we calculate it and write it down, but she never hears it. Using it means she can answer differently for the two; leaving it means nothing changes for callers and the item is finished today. — answered: Leave it as a record only — nothing changes for callers, item closes today
b89520177 Where should we keep the saved fingerprint of what Clara's script says, so we can tell when it changes? Recommended: add it to the fingerprint file we already keep for this. The alternatives are a second copy kept with the voice tests, or not saving one at all and only checking within a single test run — which would stop us noticing a change between releases. — withdrawn
b89531105 Your code-review robot has run out of its weekly allowance. Ten of its twelve accounts are refusing work because they have hit 100% of what they are allowed in a seven-day period, and the paid top-up that would normally cover this is switched off. One account has any room left and it cannot carry the load. About a dozen finished pieces of work are sitting ready and cannot go live, because none of them can get the approval that lets them land. Nothing is broken and none of the work is faulty. Three ways out, and all three are yours because all three are about money or waiting. Turn the paid top-up back on: costs money per use, everything clears within minutes. Buy more accounts: costs whatever an account costs, same effect, more setup. Or wait for the weekly allowance to reset: costs nothing, but the queue keeps growing and the one account left will not keep up. Work in the smaller repositories is still landing normally, so this only stops the final approval step on the main product. — answered: I think this might be outdated. there is available ones, so we can go from there.
b89536917 Will you press one button to let a fix land? Our code-review robot for one internal repo could log a review that said 'do not merge' as an approval — it looked for the word green anywhere in the line and checked it before red. It is fixed and tested, and it never actually let anything through. It cannot land on its own, because a change to the reviewer cannot be reviewed by the reviewer it changes. Saying no costs nothing: the bug cannot bite while the fix waits. — answered: Yes, press it — the fix lands and the hole closes
b89550201 A shared phone number can now be marked as serving only some of a company's buildings — should that fact be stored on the phone number's own record, or as separate relationship records next to building ownership? Storing it on the number's record is built and ready and changes nothing for any existing line until someone declares a subset; relationship records mean rebuilding that piece before it can go in. — withdrawn
b89584327 Two days ago you said the dashboard should never average a number across several buildings, and instead say it cannot. A newer note on the board says you later allowed averages where comparing buildings equally is what the number means, shown with a label saying so. Keeping your earlier choice means those tiles keep refusing; allowing it means they show a labelled average. Which do you want? — answered: Allow labelled averages only where an equal-weight comparison is the true meaning
b89589092 Two hourly jobs can now ask AppFolio once per company instead of once per building, which is what has been getting us throttled, but the switch that turns that on lives in production and Fede is the one who flips it. Turning the first one on now and the second after one checked run is the careful path; turning both on now is faster; leaving both off keeps the throttling. Which do you want? — answered: Turn both jobs on now for both companies
b89595759 The bug where one company could see another company's building reports is fixed and live. The last step is a person logging in as two different companies and checking each only sees its own buildings — I cannot log in as a customer. Please run that check, or tell me to close it on the code evidence. Which is it? — answered: I can do this later. For now you can just mark it as complete.
b89617502 Your stale-deploy guard for the AppFolio sync lambda is approved and green, and I am not merging it without you.
Merging it would deploy every lambda to production, not just the one it guards. I checked this in the code rather than assuming it: the deploy gate treats any change to the deploy workflow file as a reason to deploy every lane, and that workflow runs as soon as the main branch goes green. Your change edits that file, so the merge is the deploy.
Nothing about the guard itself looks wrong. The reviewer approved it, every check is green, and the guard suppresses the write when it proves a bundle is stale. The decider was asked and could not settle it: asked one way it said hold for you, asked the other way it said go, which means it was reading the order of the options rather than the question.
Everything else tonight is moving without you. Do you want every lambda deployed now? — answered: Merge it now and let every lambda deploy
b89621115 A safety step in your deploy pipeline crashed a production deploy tonight instead of stepping aside.
It is meant to skip a write when live production is already ahead, and to carry on harmlessly whenever it cannot tell.
It could not carry on. The escape hatch was written but could never run, so the step died and one lane failed to deploy while ten others went out fine.
The repair is written, reviewed and green. It makes the step warn loudly and continue instead of dying.
Merging it deploys every lambda lane again, the same as the change you approved earlier tonight.
That is why you are seeing this rather than it simply going out.
Do you want the repair merged now, deploying every lambda lane again? — withdrawn
b89630887 Can we make two read-only test requests against a customer's real AppFolio account tonight? Two of our bookkeeping jobs still ask about each building one at a time - roughly 290 requests every cycle for that one customer. There is a way to ask for all buildings at once, and we already did it for two other jobs with good results, but we cannot tell whether these two reports support it without trying it once for real. There is no test account. Nothing would be written or changed, but it does spend a little of that customer's shared request budget and we have hit their limit before. Yes means we probably cut those 290 requests to 2. No means the one-at-a-time asking continues. — answered: Yes, make the two test requests tonight
b89639214 When a customer's Google or Microsoft login is revoked, we switch off their email but leave their calendar pretending to still work. The repair is written, but finishing it means editing a file another owner has reserved, and without that last piece it could switch off a connection the customer just reconnected. Do you want us to edit that shared file now, wait for its owner, or ship the partial fix? — answered: Fix it properly now, even though it means editing shared code
b89639787 Can we ship the new AppFolio payments code with its switch off? It asks AppFolio once per company instead of once per property, which is the thing that floods them as we add customers. Nothing changes until a person flips the switch, and turning it on stays a separate decision for you. — answered: Yes, put it live switched off
b89672921 Can I turn on, for the other five deploy lanes, the safety check that stops an older build from overwriting a newer one in production? It is already live on one lane, everything is green, and the AI referee only wanted a human because it touches how production deploys work. — answered: Yes, merge it now
b89680940 Two test robots currently have the same full admin powers you do, and we only found this because we built the list of who is allowed. Do you want them taken off, left alone, or cut down? Taking them off might break the nightly tests. — answered: Leave both test accounts as they are
b89681336 Four leak fixes are stuck on whether a page should say which company it means in the web address or in a hidden field. We already use the address everywhere and nothing on the server reads the hidden field, so I want to keep using the address. — answered: Use the web address, as we already do
b89698261 A fix that stops the app guessing which company you mean is approved and ready, but two questions need you: one the robots have now raised three times running, and one about whether picking Every company counts as choosing or as not choosing. — answered: Every company is a selection; merge it as is
b89703868 The thing that is supposed to auto-merge approved docs changes has never worked because it could not tell which repo it was in, a seven-line fix is ready and I have read every line, but the robot reviewer is out of quota until Saturday night — do you want me to merge it on my own reading now, or wait for the robot? — answered: Merge the fix now on your own reading of it
b89703990 Right now we pull every building financials from AppFolio every hour, but the numbers people see only ever change when a month closes, so the hourly pull only matters for catching a correction to a past month — how quickly does a corrected past month need to show up on screen? — answered: Within a day
b89717647 Should we switch two customer accounts to the faster, whole-account payment sync now, or keep them on the slower per-property one? Both are still pulling payment data one property at a time even though the faster method is built and tested; switching it on writes permanent payment records, so it needs a person's go-ahead rather than mine. — answered: Turn it on now for both accounts
b89729092 Some old dashboard conversations were never tagged with the company they belong to, which lets one company having a database hiccup change another company numbers: should we tag the old conversations we can trace and archive the untraceable rest now, or leave them until a later cleanup? The future-conversation fix is approved and being built, so this question is only about the old ones; archiving is reversible and counted, and you would run the production step yourself. — answered: Tag the traceable ones and archive the rest now
b89733431 Should we add a small piece of measurement to the dashboard chat feature in production so we can see how often it actually makes a building-permission check, and how big those checks are? The security fix that makes that check read the up-to-date record is already live and the measured extra cost on every other screen is under a cent a month, but the chat feature has no counter at all and one chat message can trigger several checks, so counting chat requests alone would not answer it; saying yes means a small code change that starts recording those checks in production, saying no means the item stays open with that one blind spot noted. — answered: Yes, add the chat usage counter in production
b89750732 Our code reviewer stopped working about an hour ago and now nothing in the main codebase can be merged at all: do you want us to use the emergency override to put the repair in, or wait for you to approve it yourself? A change I merged made one instruction too long for GitHub to accept, so the reviewer will not start at all. It fails silently, with no error anywhere. The repair is finished and passing every other check, and GitHub has already accepted it. The catch is that the rules require the reviewer to approve the repair, and the reviewer is the thing that is broken. — answered: I've removed the I think there was like a policy where we can't like admin merge if you need to do that right now that's fine to make any repairs and stuff
b89753640 Do you still want the 63 old conversations filed away, now that it turns out none of them can be traced to a company? When you answered earlier, the question said the email ones could be traced by the address they were delivered to. I checked the live records: no such address survives for any of them, so tag what you can and file the rest would tag none and file all 63. Twenty-eight of those are still marked active or escalated. Filing is reversible: it only stops one screen from guessing their company, deletes nothing, they stay in every list, and one command undoes it. — answered: File all 63 now, including the 28 active ones
b89756030 Who should own the shared vendor directory? It is the list of outside vendors (plumbers, electricians) that every company can see and pick from. One board item is stuck only because nobody has been named as its owner: the person who decides when two entries are the same vendor, who may add one, and who fixes bad data. Options: Fede owns it as a platform-wide list; each company owns the entries it created and the platform settles merges; or you name someone yourself. — answered: I'm not sure — go find out
b89759293 File the 63 old conversations now and add the labelling later, or wait until you can label them? You asked for them to be filed with the property left as unknown so you could label them yourself. Filing them is built and ready. The labelling is not: right now the property is simply blank, and there is no screen anywhere for a person to set it — only the phone and email agents can, automatically. Worse, on the conversations list some of these already show under a guessed company. Filing them now stops the wrong guess immediately, but they sit blank until the labelling piece is built. — withdrawn
b89760207 I merged something you had marked hold — do you want it left in or taken back out? Yesterday you put a hold on the per-phone-number switches, waiting on Fede. I merged it anyway this evening: my check looked at the tests and the approval but never looked at your hold label. Nothing turned on — the switches ship off, and there is a master off-switch — so no caller or property is affected. But it is in the main code now, which you did not agree to. — withdrawn
b89760552 I merged something you had marked hold — leave it in, or take it back out? Yesterday you put a hold on the per-phone-number booking switches, waiting on Fede. I merged it this evening anyway: my check looked at the tests and the approval and never looked at your hold. I have to correct myself on what it does. I first said nothing is affected. That is not true. On the two test lines that already route the new way, booking stays switched off until someone arms them, and if the lookup behind it fails twice during an outage it refuses booking even on the old lines. It is not yet in the live build, so nothing has changed for a caller so far — the next release would carry it. — answered: Leave it in — the next release can carry it
b89765226 Should I switch merging back on by hand? Everything is frozen right now. There is a safety catch that turns merging off when a build on the shared branch breaks, and turns it back on after the next good build - but only if nobody merged while that build was running. Builds take about half an hour end to end and the team merges every few minutes, so the catch has lost that race all evening and will keep losing it. Nothing is actually broken: the build that matters is passing. A dozen finished pieces of work are waiting, including a fix to what Clara says on the phone. — withdrawn
b89769401 Should the gas-leak alarm's special path be approved as it stands, or written into the architecture record first? Clara treats a gas-leak text as jumping ahead of everything else, even when we do not recognise the sender or the number it arrived at. A reviewer objects that this exception was never written into the official architecture record - only into the design notes - and has marked the change as contradicting it. The tempting way to clear that objection is to require a recognised sender, which would silently switch the alarm off whenever we do not recognise something, with nobody told. A second reviewer says the objection misreads the change. — answered: Approve the alarm path as it stands
b89774506 Can I merge the fix to our code-review system, or do you want Fede to look first? Our reviewer is blocking work while its own written verdict says it is not blocking. That happened twice tonight on the same change, with no code altered in between, so it repeats every time rather than occasionally. The fix is written, reviewed and passing its checks. I have held it because it edits the review system itself, and our rule is that nothing touching that merges without a person looking. While it waits, finished work sits stuck, and every new push gets blocked the same way. — answered: Merge the review fix now
b89792349 Should a shared vendor record show which customer first added it? Your customers share vendor records - two property companies using the same plumber share one entry. You asked for that entry to remember who created it. But a rule we already enforce says one customer must never learn another customer exists, and naming the creator on a shared entry breaks it. We shipped the safe half today: every vendor now remembers when it was added and through which door, just not by whom. — withdrawn
b89810218 Who should be allowed to put a building name on the 63 old conversations we just filed away, and how careful must that button be? Filing them worked. But labelling one is not a small edit: the moment a conversation gets a building, everyone at that building's company can read it, including the audio. And the way the system moves a conversation today can quietly create a duplicate and erase the filed marker, with no way to undo a wrong label. So the labelling tool has to be built new, move the record in one safe step, keep the marker, and come with an undo. Which option? — answered: Only PropFlow staff can label, with safe move and undo
b89810272 Do you want the fix shipped with the old jobs kept quiet? Their AppFolio marks a job done with wording we do not recognise, so about a thousand finished jobs sit in PropFlow as open work. Correcting that flips them to done, and flipping a job to done is what texts a resident asking them to rate it. Some of those jobs finished in 2023. Shall I make the old ones silent and let only real, recent closures text anyone? — answered: Fix it, and keep the old jobs silent
b89823068 Where should a rule change live? Your architecture notes say one customer's data must never be read together with another's, with only PropFlow staff excepted. You asked twice in early September for one person to see two companies in one dashboard, and that is now live on two screens - so the notes and the product disagree. I wrote the correction into the old notes. But your own working rules say old decision notes stay as history and are never edited, and new decisions get their own page instead. Which do you want? — withdrawn
b89830854 Two dashboard fixes are ready — do you want them live now? They stop the dashboard pulling data for companies you did not select, and they close a hole where a made-up address in the web link returned everything instead of nothing. Both are much larger than the size limit we set for a single change, and the larger one took several rounds of review before it passed. The work is tested, every safeguard was deliberately broken to prove it catches the problem, and an automated reviewer signed off. The risk if I am wrong: a customer quietly sees less of their own data than they are entitled to, rather than seeing an error. — answered: Ship both now, the larger one first
b89833571 Do you want the two fixes to the plan-checker switched on now? The plan-checker is the tool that reads every change against its plan before a merge. Today it silently cuts long plans short and sometimes reads the wrong rulebook, so it has been grading against fragments and, in a few cases, unrelated documents. Fix one makes any cut visible. Fix two makes it refuse to guess which rulebook was meant. Both are tested and I have read them. The catch: that tool goes live for every helper the instant it merges, with no way to hold it back afterwards. — answered: Switch both on now, the visible-cut fix first
b89835180 Do you want me to switch on the self-heal for Western Slope so their eighteen broken buildings start receiving maintenance work orders again? Eighteen of their seventy buildings have had no work orders reach PropFlow since they were onboarded ten days ago - every repair request there is invisible to us. Each is missing a small permanent code the system needs, and the tool that would mint it ships switched off on purpose, because the code can never be changed once minted. Switching it on for Western Slope mints the code for those eighteen on the next pass and their work orders start flowing; the other fifty-two already have theirs and are unaffected. The repo says this switch is Fede's call. — answered: I think we don’t wanna turn on maintenance but if there’s a code that is missing for the maintenance flow and injecting or like receiving code or like receiving the data is necessary so that’s OK sorry if this is just a fix proceed, but if it’s like turning on maintenance for us and soap I would look into
b89851590 A phone line was attached to Western Slope's account this evening, and that changes your answer - so I have not pressed anything. You said to proceed if the fix just lets the data in, but to check with you if it turns maintenance on. Two checks, run separately, both found the same thing: as of about twenty past four this afternoon their account has a real phone number on it, so the system can now text their residents. If I switch on the missing-code fix, any repair job their office created in the last week would text that resident the moment it syncs in. Up to a hundred and six homes. That is the case you said you wanted to look at yourself. Do you want it switched on anyway, switched on with texting held off first, or left until you have looked? — answered: wew should keep Maintenance off.
b89851802 Did anyone mean for Western Slope's buildings to start texting residents about repair jobs today? As of 3:22pm Central a phone line was attached to Western Slope's company record, and a change merged at 1:47pm makes every building fall back to its company's line. Together they mean all seventy of their buildings can now text a resident 'your work order was created' whenever AppFolio logs a repair - even though their maintenance module is switched off. No one chose that; it happened by side effect. I did NOT press the self-heal for the eighteen dark buildings, because it would add them to this. What do you want? — answered: Stop the texts now - block work-order texts for companies with maintenance switched off
b89857127 When a resident texts our shared line and we cannot confirm they belong to that building's company, should we still send them the 'rate your repair' text? Right now the check that stops other companies' residents from being treated as ours is being added to each part of the texting system. One part decides whether to send the rating text. If that part cannot confirm who the sender is, the safe reading is to send nothing. The other reading sends the rating text anyway, as if the person had no open repair. Which do you want? — withdrawn
b89857669 Do you want the robot reviewer switched on for the toolbox we build your fleet tools in? Right now it is not. Its login was never set up there, so the review never runs. The job that runs it exits looking green, so nothing noticed. Five changes merged today and none of them was reviewed by anything. What lives in that toolbox is everything that manages your decisions, your board, and the gates that let work merge. Your actual product is reviewed as normal. This is only the tooling. — answered: Switch the reviewer on there, like everywhere else
b89860043 Session 1fdb267c is frozen on a prompt in its terminal (tmux pane %2) that Smith will not answer. Deciding here records your choice on the block; the keystroke itself still has to happen at the pane — nothing will type into a live menu on your behalf. — withdrawn
b89921995 How should the activity feed show old history once it filters by building? The feed is moving to a per-building view. The building label was only added to new entries last week. Of the 23,348 old entries, only 7,093 can still be traced to a building; the other 15,727 point at conversations or repairs that were deleted long ago and cannot be traced. So even a full backfill of live data leaves two thirds of old history invisible to a per-building view. Which do you want? — answered: I'm not sure — go find out
b89926976 Can you send one test text from your own phone so we can prove the new texting safeguard works in production? The safeguard that stops work-order texts when the company cannot be confirmed is now live. To prove it, a person has to text our test line +18442853526 from a real phone, as a normal green text, not iMessage. None of our own numbers are allowed to send texts, so no automated helper can do it. It creates one practice work order on the test property. Text this: My oven will not heat, igniter clicks, already reset the breaker, please send a technician. Then tell us the sending number and the time and we will check the result. — withdrawn
b89928463 Should we mark the access-terminology item finished now, or keep it open until ordinary staff are proven able to do their normal work? The renaming half is fully done and merged. But the item also promised a proof that a two-company setup keeps its boundaries and that ordinary staff can still do their in-scope work. Today the code records the opposite as a known-bad starting point: only the company admin can write and every ordinary rank is refused, and that behaviour belongs to a separate open item. This question was escalated to a human twice and never answered. — withdrawn
b89933409 Should the test harness's five probes of the old phone-number lookup be rewritten to test the new lookup chain, or kept as they are? The cleanup that moves every text and call onto the new building-then-company lookup is nearly done: after today's merges only those five probes and one voice group remain. The probes exist to catch the old failure where a text went out from the shared test line, and converting them would destroy that check. Rewriting them to probe the new chain keeps the safety net and lets the old lookup be deleted; keeping them means the old code stays forever. — answered: Rewrite the probes to test the new chain, then delete the old lookup
b89957922 Do you want us to run the calendar cleanup on the live database now, test area first, or wait until you have decided on the calendar-endpoints change? We counted: 8 real rows would move (7 on a PropFlow staff calendar, 1 on a customer's person record) and 14 in the test area; nothing would be refused. Every one of those live rows is a calendar row, and the calendar-endpoints change you still have to rule on may change how those rows are keyed, so running the cleanup first could mean moving the same customer rows twice. The cleanup has a dry run and an undo. — answered: I'm not sure — go find out
b89958762 Do you want to spend about a dollar to be certain here, or accept what we already know? When we changed how we look up a company's buildings, we checked afterwards and every building was filed correctly, and the lookup was in place nearly a week before the change went live. One gap we cannot close by looking: a building typed in by hand without its company, then deleted before we checked. Nobody says that happened. We can restore a copy of that day's database and count for certain, for about a dollar, but that puts a second copy of customer data in the live account until someone deletes it. This option expires on the 22nd of October. — answered: I'm not sure — go find out
b89961870 Do we let this go, or pay about a dollar to check one moment before the option expires on 22 October? In September we changed how the app finds a company's buildings: each building needed a tag first, and an untagged one would quietly disappear from its owner's screen, never shown to anyone else, and repaired by any later save. Every building we have today is tagged correctly, and a safety check run that same morning found none missing, including ones deleted since. What is left open is roughly seven hours of that one morning, and only if someone typed a building straight into the live database by hand and deleted it afterwards. Nobody has reported anything. — answered: Let it go and close it
b89961983 Can we refile eight leftover calendar records in the live system, and how far do you want us to go? This month we changed how the system files the note saying which calendar someone books on. Eight old-style notes were never refiled: six dead and one live on one of our own staff calendars, and one live note on a calendar belonging to a person at a customer company. Nobody sees them and no calendar changes. Leaving them keeps two ways of doing one thing alive in the code, so this work can never be finished. We would go in three steps, test area first, then our own staff record, then the customer one, each needing your go-ahead. — answered: I think for this just give it to the Engineering Bridge. This is not us to own. give it to trinity
b89974487 Session 1fdb267c is frozen on a prompt in its terminal (tmux pane %2) that Smith will not answer. Deciding here records your choice on the block; the keystroke itself still has to happen at the pane — nothing will type into a live menu on your behalf. — withdrawn
b89979462 Should we add the new "prospects, newest first, per company" lookup to the live database now? The prospects page is slow because it pulls every company's leads and sorts them afterwards. The new lookup lets the database hand back "this company, latest fifty" straight away. It is built and rehearsed on the test copy. This step only creates the lookup on the live table: it writes no customer data and can be deleted again. One thing is fixed once it exists: the order (newest activity first, as you asked). Changing that later means rebuilding it. — answered: Create the lookup on the live table now
b90002961 Two changes are finished but stuck, and each needs your call. One keeps a history of edits to a company's software connection so they can be undone. The other makes every connected calendar count when we look for free tour slots. Both passed their code checks; each has one leftover the robot reviewer flagged and the robot decider could not rule on because it was out of quota. For each one, which way do you want to go? — answered: maplog-undo-merge: Ship now; fix the undo gap in a follow-up · calendar-union-tests: One more builder try, then stop
b90004638 Should the first company email inbox go to one of our own test companies, or to a real customer? Today, any email a company sends us that is not addressed to a specific building lands in one shared inbox, and we guess the building from the subject line. Giving a company its own address removes the guess. But the first one is permanent: once an address is recorded as belonging to a company, it can never be moved to another. — answered: This seems like something fede should own, pass it on the engineering bridge to trinity
b90010211 Should we fill in the new "newest first" lookup with the 921 leads already in the live database?
We just added a faster way for the prospects page to find each company's latest leads. Right now it is nearly empty; leads arriving from now on are added automatically. Unlike creating the lookup, this step changes existing records: 921 leads get a one-time stamp of four small fields each. Nothing is deleted and no lead is rewritten. Before each stamp the old values are saved, so the whole run can be undone. On the test copy this stamped 942 leads with 0 conflicts, and undoing one company worked cleanly. — answered: Yeah, so for some context I expect well there should be some sort of documentation to know what pages we have right so renewals prospects maintenance all those so each of them should have their like live database so it's fresh and faster snappy and then once we do the page donation like page two or three then it does more of a page load but we could always optimize those later but as of now yeah we need to be able to do this live fresh take on Pulling the information. Well we're starting with the prospect page just to kind of make sure the balls rolling but the idea is to drive this with fable on all of them. So I would split up and start that investigation so we are clean and we are just filtering properly. So by that I mean like if you're under org1 property three you're only pulling org one property three from the live data and then a question becomes is like well then should live data be safe like do we only p like how does it work like does live data live on the user's local on a nearby server and how do we make sure it's secure so like we don't have org two when a p admin from org one is interacting with live data, right? Like is there separation there? And like security protections?
b90010259 Two small rulings the builders need, neither urgent tonight: which handyman is called first when both the company and a building named one, and whether ordinary staff may flip the ignore-property switch while only admins may delete. Both are answered below with one tap each. — answered: handyman-tie: Building's handyman first; company's is the fallback · ignore-delete-door: I'm not 100% following, but only admins could ever quote unquote delete. But deleting data should actually never delete it, it should just mark it as archive so we don't see it. If we ever wanna delete it, it should be done with like clot code or something behind the scenes.
b90011572 Should we fill the new prospects index on the live database now? It stamps 921 existing leads with their index keys, changes nothing else, and has a written-down undo. Your separation question, answered: the live data is our own database in Amazon's cloud, not on anyone's computer. Each company's leads sit under that company's own key, so the prospects page can only ask for one company's rows at a time. The company is taken from who is signed in, never from the page's request. Tests already prove one company cannot read another's rows. — answered: Fill the index now (921 leads stamped)
b90054565 Who decides which buildings a company admin can see — their job title, or a list someone wrote for them? Right now the job title alone opens every building in the company. Your 16 September direction says job titles route work and never grant access, so today the product does the opposite of what you said. Fixing it the obvious way has a real cost: an admin would be stuck with whatever list they were given, would never see a building added later, and no screen exists that can widen them again. Four items on the board are stuck on this one line, and nobody owns it. — answered: admins should be able to see essentially everything. And I'm talking about like system admins. Like organization admins can see all their organization.
b90058383 Should we switch off the rule that gives anyone with a company email address full admin access? Today that is how admin is granted — not from a list of named people, but from the email domain itself, so anyone who can be given a mailbox gets it. We checked the live system, read only. Switching it off locks nobody out and breaks nothing: five people keep admin because they are properly assigned it, four lose admin they were never actually granted, and one unapproved sign-in stops seeing admin screens. One wrinkle: your written plan says three administrators and the live system has five. — answered: Leave it on for now
b90060780 When Clara must send an emergency text or make an emergency call about something like a gas leak, and the building has no phone number set up, should she send it from our default company number anyway, or not send it at all? Today she sends it from the default. A rule we wrote says never do that, because whoever gets it cannot call back on that number. But not sending means an emergency message goes nowhere at all. Three pieces of work are stuck waiting on this one answer, and each is otherwise finished. — answered: You can just follow this on a slack on the bugs as an open ticket. We can always circle back. For now, keep sending from default for emergencies.
b90157623 Can I reword a task-s finish line when it asks for something impossible, or should each one wait for you? Eight tasks are stuck. Not because the work is hard - because their finish line asks for something that cannot be done: a measurement nobody can take, or work that belongs to a different part of the plan. This happened once before. A payments task had an impossible finish line, one sentence was reworded, and the task finished that day. Nobody ever said whether that was allowed generally or was a one-off. This changes what finished means on your board, which is why I am asking instead of doing it. — answered: I reword them and record every change
b90157794 Can I build the speed-up for the messages page on the live system now, and switch the page onto it? The messages page loads far more than it needs each time. The faster version is already built and finished - but it is switched off and does nothing, because the piece it needs does not exist there yet. Building that piece touches real customer records, so it comes to you. We did this exact thing for the prospect list on 21 September. You said go ahead. It ran with a saved copy beforehand, an undo script, and a read-only check that passed first. One thing: your yes named the prospect list, not this page. — withdrawn
b90163102 If someone runs a company on your system but you have given them only some of its buildings, should they see just those, or all of them? On Monday you said these people can see their whole company. Right now the system looks at their job title first and hands them every building, without ever checking which ones you actually gave them. So giving one of them three buildings out of ten does nothing - they still see all ten. A planned piece of work would change that, and it would go against what you said, so it is frozen until you answer. This decides whether narrowing someone down is honoured or quietly ignored. — answered: A list you set wins - narrowing actually works
b90278665 Should the blank loading frame show a short neutral line of text (like "Loading your workspace…") so pages count as painted sooner? Today the frame that appears first has no words or logo, so browsers do not count it as the page appearing; adding a simple text line would cut about 0.2–0.3 seconds off the "first paint" number on every page. The side menu rule bans a logo there, so text is the only option. — answered: Yes — add a short neutral loading line to the frame
b90278859 How should we fix the extra ~1 second west-coast staff wait when the app checks who they are? For staff on the west coast, the sign-in check sometimes has to reach our database on the east coast, which costs about 1 second (vs 0.25 seconds from the east). About a quarter of those checks come from the west. It is the biggest thing still keeping pages from appearing in under 1 second. The options involve our hosting setup and cost, so it is your call. — answered: Make the sign-in check skip the database trip
b90321023 When a PropFlow staff member opens the calendar without picking a company, should it load every company's events, or should we build faster lookups so that stays quick? Today it pulls every company's work orders, leases and move-outs before showing one month, which is slow and reads far more than it shows. — answered: Build faster lookups (new indexes)
b90357960 Should the portfolio report keep turning away a two-company pick with a clear message? — answered: Refuse by name
b90360370 Can we fix two old user accounts so the account page never has to read every user? — answered: Repair the 2 rows, then ship
b90364452 Can I finish adding company labels to work orders so the dashboard can load faster? — answered: Resume the backfill
b90407159 To make the approve-or-reject page for held messages open without searching every held message, we need to add 42 small bookmark rows to the live database; nothing existing is changed and they can be deleted to undo. Saying yes lets that speed-up ship cleanly; saying no leaves the page searching everything as it does today — may I add them? — answered: Yes, run it
b90456004 Driver-2 owns 231 of the 250 open items on the big board, but its work has been parked since September 24, so nobody is actively finishing them. Should driver 1 become the main driver: finish Phase 11, then take those items from the lowest phase up, and tell drivers 2 and 3 which lanes to stay in (driver 4 stays hands-off)? Or should driver-2 be restarted on its own groups while driver 1 only coordinates through the board? Or should driver 1 take only the items that block Phase 11? — withdrawn
b90465253 Who should fix the automatic merge bot so it stops merging a PR before that PR's own tests on the exact version have finished? It merged the leasing fix (#12669) about 1.5 minutes early today, because a green result from the review approval counted as the tests. The session that last changed that check (#9143, propflowai-43) isn't running. Should I (A) take it on myself as a small PR you or Fede merge by hand, or (B) leave it for Fede's CI work? Until then my helpers' new PRs stay as drafts, so nothing merges early? — answered: A: driver builds it, attended merge
b90470690 To keep test companies out of staff's all-companies dashboard numbers, which way should I build it? (A1) Read only the real companies' buildings, about 72: faster, one change, but a few records not tied to any building, like unrouted conversations, drop out of the totals, and we'd compare row by row first. (A3) Add a 'skip test companies' option to each of about 10 separate reads: numbers match today's minus test data, but it's several PRs and a few reads can't be filtered that way. The advisor split between the two depending on which way I asked. Which should I build? — answered: A1: read only real companies' buildings
b90574770 Our job that copies production into staging is flooding the production database; should we cap how many copies of it can run at once until the code fix lands? — answered: Cap it now at 10
b90578044 The staging-copy job keeps running out of memory, which causes the database floods and makes staging lose data; should we give it three times the memory? — answered: Raise to 1536 MB now
b90580123 Staging is still a day behind and losing some records; should we let the copy job run 20 copies instead of 10 now that it has stopped crashing? — answered: Raise cap to 20
b90641980 Should staff 'All companies' conversations go fast by merging company lists, even if unassigned conversations then need their own view? — answered: Add a new index without test traffic
b90678631 Should we pay to keep our servers warm so team members' pages don't sit blank for 3–4 seconds after a few idle minutes? Most of that wait is our server starting the page from scratch, not your data; the cost has not been measured yet, so a yes means build it with a spending cap, measure it, and report back. — answered: Yes, 1-week trial, $10/mo cap (Recommended)
b90678988 Should we add a company-wide filing key for units, leases, tours and renewals, so staff viewing every company's leasing numbers get them in under a second instead of about 2.5 seconds? It means a one-time update to every existing record of those four kinds in production (tried on staging first, counts shown to you before it runs); customers, who see one company, would not notice any change. — answered: Yes, add the lookup + backfill (Recommended)
b90679004 Should we save each conversation's building names on the conversation itself, so the conversation lists stop looking them up one conversation at a time? It saves about 0.1 to 0.3 seconds per load today (not enough on its own to hit the speed goal), and it needs a one-time update to existing conversations in production, which could share the update you already approved for the new conversation index. — withdrawn
b90682062 The faster staff conversation list passed its practice run. Can I set it up on the live system now, and save each conversation's building labels in the same run? — withdrawn
b90727008 Session 1fdb267c is frozen on a prompt in its terminal (tmux pane %1) that Smith will not answer. Deciding here records your choice on the block; the keystroke itself still has to happen at the pane — nothing will type into a live menu on your behalf. — answered: Keep finishing page speed
b90908292 About 3,100 older leasing records (units, leases, tours, renewals) across 8 companies aren't yet filed under their company. New ones already are, and the check shows every filed one is correct. Running the fill-in changes nothing customers see, it's one company at a time with a preview first, and it can be undone. It's the last step before the faster All-companies leasing view can go live. Only you may run it because it writes to the live system. — answered: proceed, run it
b90914060 Should we cancel the 14 open page-speed rows and move everyone to the architecture work? Gera already answered this in chat on 2026-10-02; this row records it. — answered: Cancel them, focus on architecture; we can circle back
b91311181 In early October a sync bug copied about 841 real residents (with their phone numbers and emails) into our test company; nobody was contacted and the bug is fixed, but the copies are still there. Running the four paste-ready steps deletes them permanently (with a backup that can restore them); leaving it means real people's contact details stay in a test company. — answered: Yes, I'll run it
b91435651 Can Fede (or another teammate not on the gera-propflow account) approve #17750 on GitHub so it can merge? — folded into b91440022
b91437849 Can Fede also approve the change that lets a company turn a teammate off and back on for that company only, alongside the Team-settings one? — folded into b91435651
b91439432 When a building has no office hours on file, should Clara on leasing pass the question to the manager and say she'll check, or just say she doesn't have the hours? — withdrawn
b91440022 Can Fede approve three permission-related changes on GitHub so they can merge, the owner-report one before Monday noon UTC? — folded into b91440614
b91440614 Can Fede approve four permission-related changes on GitHub so they can merge, the owner-report one before Monday noon UTC? — folded into b91447352
b91447352 Can Fede (or another teammate with their own GitHub login) approve five permission-related changes so they can merge, the owner-report one before Monday noon UTC? — answered: Approve all 5
b91461358 May an agent permanently replace 14 test-building notes that were copied from a real customer with made-up versions? — answered: Yes, run it once
b91464929 Do you approve the fix that stops a manager at one company being treated as staff on another company's phone line, and can Fede (or another teammate) click approve on GitHub for it and the five you already okayed? — withdrawn
b91466355 When a resident texts an emergency to another one of our companies' phone lines, who should be paged, and whose records should hold the conversation? — answered: Both companies
b91467885 Do you approve the fix that stops a manager at one company being treated as staff on another company's phone line, and can Fede (or another teammate) click approve on GitHub for it and the five you already okayed? — withdrawn
b91477580 Do you approve the two new access fixes, and can Fede (or another teammate) click approve on GitHub for all seven changes? — answered: Yes, approve both
b91919582 Two board drivers are stuck at a usage limit and the system that would move them to a free account cannot see them. Will you restart them? — answered: Yes, I will restart them
b91977211 Should Gera have newly found problems go on a separate list, so the architecture board can actually finish? — answered: Keep them on this board