How much work is left

The operator product, and the one a poker room pays for. Live, and now in front of real outside staff.

• A first live rehearsal. The tournament-to-payout pipeline has been verified in testing but never run end to end during a real event. This remains the highest-value validation left, and with 23 days to the event it is now also the most time-critical. Not started.
• The five-surface simulation on one machine: kiosk, window, dealer tablet, screen and phone running one small tournament together. It is the only way to see four of the six notification categories fire, because they can only trigger while a tournament is actually running in our software. Not started.
• External reviewer feedback. Two employees of a real poker room hold operator accounts and are reviewing the app. The pass is still running.
• A Windows desktop version, so an entry ticket prints automatically the moment a player registers. A browser cannot do that.
• Turning on tournament scoring. The engine is built and live; as of 3 September none of the 32 rooms has selected a scoring style. See the note below.
• Two gaps a competitor covers and we do not, both newly written down rather than newly true: must-move, the rule that consolidates short tables, does not exist in our product at all, and a player can only sit on one waiting list at a time.
• Operational completeness: activity logging, recurring-event editing, and registration open and close controls. High-hand promotions have come off this list.
• A broad styling defect affecting colour rendering across roughly 300 places. Cosmetic, but wide.
• Shipped since the last edition, and it is the largest operator gain in months. High-hand promotions went from a gap to a working feature in two phases: the dealer calls it from the table, a manager validates or rejects the award, and the amount is recorded against a promotion. Signature capture on a tablet shipped alongside it, which is what turns a prize award into something a room can evidence later, and it was a roadmap item a fortnight ago. Staff can now create a player account at the desk, which high hands needed and no screen offered. A cash defect that let one player hold several live seats was closed.

A touchscreen at the door of the poker room. New since the last edition: it did not exist on 26 August, and it is now the tenth deployed application, live at kiosk.tblmaster.app. Built as a permanent RoomDirector module, with September as its first configured event rather than a one-off.

• What it does today, in production. A player who signed up on the event site types their phone number and is checked in. Anyone new gives a name and a phone number on an on-screen keyboard. It also carries the tournament schedule, read from the same live feed as the consumer site, and a searchable leaderboard for the room, reading the same feed as the embeddable card already serving on their website. Between players it rests on a rotating idle screen.
• The one item left is an hour on the real hardware. Full-screen mode on the HP touchscreen at the door, the USB keypad, the idle reset and the automatic return from a finished check-in, all on real glass rather than a developer's browser. Nothing about it is a build.
• Why it went this fast. Every part of it already existed somewhere: the registration call that assigns a table and seat, the signup list with phone numbers already stored in a matchable form, the public tournament feed, and the leaderboard card. The kiosk assembled them behind one screen rather than inventing anything.
• One standing reminder: a demonstration signup row is deliberately live so the flow can be shown, and has to be removed before the event.

iOS and Android. Built, with subscription purchases and push notifications both verified end to end on a real device. The nearest revenue surface, and the one with the most items still open.

• The store submission package: screenshots, descriptions, and both the Apple and Google privacy questionnaires. It has been the critical path to the stores since push finished on 24 August, and it has not started. It is not blocked by anything; it is about a day of careful paperwork that nobody has sat down to do.
• Four faults found in a deliberate bug sweep across 1 to 3 September, and still open. An Android confirmation email opens a browser instead of the app, because one small file is missing from the website that vouches for it. The two digest notifications default to off, so as written no player would ever receive one. The nine o'clock alert routes to a screen that does not answer it. Room logos are shown without a per-room permission, which has to be gated before the app is public.
• Carry-over polish from the pre-launch review pass, and a set of error-reporting rules that currently file ordinary user actions as faults.
• A featured slot on the app's home screen, hard-coded first and operator-controlled later.
• A side-by-side against the closest competitor app, in progress, to sharpen what the listing should claim.
• Shipped since the last edition, and most of it was found by looking rather than reported: new players were landing on the home screen and skipping onboarding entirely; setup screens ran only after a restart, not after phone verification; a taken handle dead-ended sign-up because the availability check always said yes; a closed sheet swallowed every tap on Android, killing three tabs at once; sign out silently did nothing when the network hung; reading every notification made the inbox unreachable; and the tab holding a player's own sessions was called Notes.

The automated nightly capture of poker room schedules and attendance nationwide. Running unattended; this is accuracy work, not build work.

• A recoverable data-loss item: several attendance figures were stored empty despite being legible in the saved screenshots. The oldest urgent item on the list.
• Same-day schedule changes are not corrected during the day.
• A single-source dependency. Florida schedules come from one public source. If it changes or blocks us, coverage stops. Adding a second source is the one item here that is a build rather than a correction.
• Grading faults, which are the sharper class: an entry-fee mismatch is currently graded as players being fine, so a wrong price on a live page shows green. A wrong number that reports itself as correct is worse than a missing one.
• Pipeline hygiene: alerting that repeats already-fixed findings, a loss that stays invisible until someone reads the morning email, shell scripts outside automated checks, and two diagnostics that write into a dead session's scratch space, one of which destroys the evidence it was run to inspect.
• Shipped since the last edition, and one of them was serving wrong data publicly: we were rewriting the event names rooms publish, and 62 rows were wrong on the live site before it was caught and corrected. Nothing had ever compared the name we publish against the name at the source; that check now exists. A dropped fee row that left a stale price on a live page was fixed, and so was the reporting job that had been calling every run broken. A room that shrinks its calendar can now have its stale events removed, and the alarm can confirm them.

In-room TV screens. Working in the building, and carrying the most risk on this page: in 23 days our tournament clock runs on One-Eyed Jack's own AV system, in front of a room full of players. This is the one section where nothing that matters has moved since the last edition.

• The sleep fault is still unchecked, nine days on. A read of the code on 25 August confirmed the screen app carries the same pattern that was found and fixed on the dealer tablet. Nobody has looked at it since. It is worse on a screen than on a tablet: the part that reports the screen as alive keeps working after the part that fetches data has died, so a frozen clock on a wall still tells us it is healthy. A room gets no warning at all. Hours of work, and the tablet's fix is a direct template.
• Still severely behind on shared packages, verified again on 3 September. Twenty-four minor versions behind on the shared database package and three behind on its own renderer, so the August fixes to the break countdown and the stat cards are not in what the room would see. Version ranges of this kind cannot cross a minor on their own, so nothing picks this up by reinstalling. Unchanged in nine days.
• Never run on the room's own hardware. Stability over a long run, at the room's resolution, driven by their AV chain rather than a monitor on a desk. Plus the clock design itself, which has only ever been reviewed against test fixtures and never against real data on a real screen.
• A Windows desktop version for true kiosk behaviour. A screen in a poker room must survive a power cut unattended, coming back straight into the tournament clock with no desktop, browser, or operating-system prompts over it. Not required for September, where a browser in full-screen mode is the plan.
• A Windows code-signing certificate, which nobody has bought. Without it a Windows installer warns the operator that the software is untrusted, which is not acceptable on a machine handed to room staff. It gates the RoomDirector Windows build as well, so it is one purchase sitting under both. Vetting a company certificate can run weeks, so it is calendar time rather than build time.
• Device credential handling, largely resolved by the Windows version, plus hardening of how a screen is paired to a room. The high-hand signage integration also lands here, now that the rest of that feature has shipped.
• Shipped since the last edition: the screen now recovers on its own after a network drop, rather than needing someone to notice and fix it mid-event. That was a required item for September and it is closed. Its access rules were also confirmed to be properly scoped to the paired device.

The public consumer site. Complete and live. What remains is commercial activation, plus polish carried over from a heavy fortnight of work.

• The coach subscription plan, built in test mode and needing live payment activation. The site's only direct revenue switch, still unflipped.
• Advertising rollout, in progress on top of inventory already serving.
• Letting a visitor pick more than one region when browsing rooms and tournaments.
• Brand system follow-ups from the partner review.
• Two small freshness bugs: a day label and an opening-hours badge that are correct when a page is built and then stop moving.
• Shipped since the last edition: Spanish is done. English and Colombian Spanish now run across the site and the shared translation package, which closes an item that had been open since the spring and takes it off the roadmap below. Room pages now carry the same trait badges the tournament list already showed, so a player browsing a room can see which events are turbos or bounties. Google's photo attribution was added where it is required. The colour-rendering defect that stood here has been reclassified to the operator product, where the same fault is wider.

Embeddable widgets that put live room data on a poker room's own website. Shipped and serving, with two of the four card types live.

• Moving the leaderboard card onto real data for the first partner room, including a monthly results import.
• A live series points race for that same room, newly started. The room is running a two-week series and has never run a points race before. A working model has been built and is with them for feedback; if they like it, the durable version is a variation of the leaderboard card that already exists rather than a new build. It is the first time a room has asked us for something they cannot currently do at all.
• Two further card types are planned rather than outstanding. Live Games and Leaderboard are shipped; Tournament Schedule and Tournament Clock are not yet built. Both are in the roadmap below. The schedule card matters commercially beyond its own feature set: it is the intended way to put our product on the website of a room that has not bought anything yet.

Internal back-office administration. Not customer-facing, and the highest-capability surface we run: it can read and change every record in the business.

• The urgent credential gap is closed. It was the largest remaining item on this surface in the last edition: a key that bypassed the front door rather than walking through it, sitting in a developer working environment. On 3 September it was rotated at source, every consumer was re-pointed, and two consumers the written procedure had missed were found and recorded. The local copies were cleaned afterwards.
• A follow-up to two-step sign-in: extending the same requirement down into the database's own access rules, so the protection holds even for a request that never passes through the app.
• Design system alignment with the standards already set in RoomDirector. A third candidate system is being evaluated for this app and RoomDirector together, rather than converging on the existing one by default.
• Shipped since the last edition: the application framework was moved off a version carrying a published vulnerability in the exact component that enforces its sign-in, and baseline security headers were added. One sign-in redirect hole was closed. Before that, sixteen pieces of work rebuilt or corrected nearly every page in the app, so counts now match the database and statuses are read rather than guessed.

The per-table tablet. Shipped and running against live tables.

• An end-to-end cash demo on real hardware. The one item left that needs doing rather than proving.
• The tablet learned to do a job the room already pays someone to track. A dealer signing in now counts a down, each dealer has a shift card, and the floor gets a night view of who worked what. That is new capability rather than a fix, and it arrived because the tablet stopped being a demonstration.
• Shipped since the last edition: the session-expiry defect is formally closed, so a tablet left asleep recovers on its own instead of needing a manual reload. The sign-in rules were also corrected: they used to refuse the four-digit codes people actually choose, and the tablet had never recorded a single shift.
• Still carrying the shared-package gap that the screen app carries, twenty-four minor versions on the database package. It is counted once, under the screen app, because it is one piece of work covering both. With a tablet on every table in 23 days, this is real work rather than demonstration.
• One open defect, counted under roadmap by priority rather than here: a dealer pressing for the floor again inside five minutes reaches nobody, because the repeat is treated as a duplicate. On the night, the repeat press is exactly the escalation that matters, so the September plan treats it as required even though the tracker does not.

The shared sign-in service behind every application.

• One pre-cutover check confirming every application identifies itself correctly before real sign-in traffic routes through the shared hub.

Cross-cutting rather than tied to one application. Details held privately rather than published here.

• A second full review opened on 3 September, ahead of both the store launch and the event. It has five phases: close the gaps already known, re-test all 67 findings from the June review, review the surface built since then, run a live attack pass, then put permanent automated gates in place so the same classes cannot come back unnoticed. Fourteen candidate findings were raised in the opening pass and are being confirmed one at a time rather than assumed.
• Phase one landed the same day. The service-role key was rotated and every consumer re-pointed. Both back-office applications moved off a framework version whose published vulnerability sits in the component enforcing their sign-in. A development file carrying plaintext passwords for live accounts was removed from the main line. Column encryption for sensitive player fields shipped, and a private function class that could be called around its own wrapper was closed.
• Encryption of the remaining sensitive player fields, beyond the notes and the columns already done.
• Abuse and spend protection before public sign-ups open, including a challenge on the sign-up form itself.
• Email authentication tightened on the consumer domain, still in progress.

Shared infrastructure consumed by every surface.

• Make live-data failures visible instead of degrading silently, so a room notices when a screen stops updating.

Not a product surface, but it governs how safely everything else ships. A five-phase automated testing rollout has now completed four of its five phases.

• Mobile smoke tests for the player app, the last phase outstanding.
• One build-pipeline blocker left: a branch in one repository cannot merge until the main line is merged into it, because that repository has no automated check for its required gate to run.
• Shipped since the last edition: the end-to-end user journeys now run automatically on every change to the operator product, which was the outstanding half of phase four. The package-access fault that had been quietly masked by a warm cache was found and fixed, so the journeys run from a clean install rather than a lucky one.

• Multi-day tournaments with starting flights. Designed and documented, awaiting sign-off. The main format gap for larger rooms and series events.
• Operator-adjustable rake and mid-event economic controls.

• Purchasable modules, so rooms buy the capabilities they need rather than one fixed product.
• Staff scheduling: who is rostered to work when. The player-facing kiosk that sat here has shipped, as has the service call centre before it.
• Table transfer requests raised at the table and actioned or waitlisted by room management.
• Food service, receipt printing, announcements, and configurable operational alerts.

• Social posting, comments and moderation on the consumer site.
• Player levels and tiers, followed-player alerts, and saved-interest discovery.
• Cross-room ranking, a normalised tour-level score rather than a sum of individual room points.

• Two further Live Cards types: a tournament schedule widget and a live tournament clock widget, joining the two already shipped. The schedule card doubles as a way to appear on a prospective room's website before they are a customer.
• Spanish in the mobile app. The consumer site and the shared translation package are done; the app is the remaining half.
• Passkey sign-in and further embeddable widget formats.
• Programmatic advertising alongside the direct-sold inventory already running.

• Framework version upgrades across two applications.
• Shared design system convergence, so all apps draw from one visual library.
• Accumulated technical debt and architectural cleanups recorded during build.

This is the sharpest thing on the page. In nine days the new code for September went from four outstanding items to effectively none: the kiosk is written, deployed and publicly serving. In the same nine days, not one of the proving items moved. The full event rehearsal has not started. The five-surface simulation has not started. The screen has not been driven by the room's AV, its sleep fault has not been read, and its packages have not been raised. With 23 days left, the constraint stopped being how much is built and became how much has been watched working. The plan carries the detail.

Until last month the system had run without external users. Two staff from a real poker room now hold operator accounts, and the event site launched publicly on 2 August. Their feedback has already produced shipped fixes, including a service call centre that was on the roadmap until they asked for it. There is still no installed base to protect, so none of the remaining work carries migration cost. One thing here needs flagging rather than reporting. The same room asked for a points race across their two-week series, which was the first time a partner pulled a feature rather than reviewing one. A working model was built and sent to them, and feedback was due on 30 August. That date has passed, and the series it was built for ran from 17 to 30 August and has now finished. The model is sound and the durable version is a variation of a card we already ship, so nothing is lost but the occasion. It needs a decision about which version to build, or an honest decision to point it at their next series instead.

Android purchase verification still waits on Google's review of a first-ever release, and app-store review itself takes several days for a new app. Neither moves faster by doing more of it. What changed is that neither one holds up September any more: the ten players at the event get the app through the tester channel, which needs no store release at all. The store work is now free to be done properly rather than quickly.