What we have
16 components: Admin, Auth, Authz, Billing, Comments, Core, Files, Founder, Invite, Jobs, Notifications, Reviews, Social insights, Web, Webauth, Webhooks.
Products built on it: Ati's Toy Shop.
saas-templateone click for ninety, one interview for nine
The template, at a glance
What exists, what is waiting on you, what changed and what is next. Everything below this is detail.
Cost this week: 38% · top: saas-main 11%
Waiting on you
3 decisions and 2 actions.
Decisions need your judgement. Actions are steps, most of them minutes.
What changed
293 pieces of work finished and merged, and 33 being worked on now.
What is next
- a product has no image of itself, so every link to it previews as a grey rectangle
- a typeface is impossible rather than absent, and the design guide's author will assume otherwise
- a product cannot ship a file, and that one gap blocks the typeface, the icon, the preview image and any stylesheet
Waiting on you
3 decisions and 2 actions. Decisions need your judgement, actions need a few minutes. Open any line for the detail.
Decisions (3)
A choice only you can make. Each one carries a recommendation you can accept or overrule.
Deploy the toy-shop update and set the family password: recommended5 minutes.
- The question
- Run
fly deployin~/workspace/projects/toy-shop, then set one family password at toys.duchovni.net/shopkeeper/family. - Recommendation
- Yes, now. The old links stop working for good, and that gets more disruptive the longer the children use them.
- Why it matters
- The children's private links are written into the shop's server log, and the wishlist page says "not found" (checked 2026-10-07).
- What it unblocks
- The wishlist, and two security fixes reaching the one live shop.
Pay Cloudflare about $5 a month so a site can be private: recommended not yetOne yes or no.
- The question
- Turn on Cloudflare's Workers paid plan, about $5 a month, or leave password-protected static sites parked.
- Recommendation
- Not yet. Say yes the day a site needs a password, and until then devops keeps building the part that costs nothing.
- Why it matters
- The password check takes about 41 ms and the free plan stops at 10 ms, so on the free plan a static site can only be public.
- What it unblocks
- Putting a password in front of a static site. We know of no live site waiting on it.
Run the admin app on Fly and save your answers in the repository: recommendedOne yes or no.
- The question
- Choose where the admin app runs, the one where you will answer these items, and where your answers are stored.
- Recommendation
- Fly, because your account is set up and paid. The repository for answers, because answers have been lost before and it is the one place every session reads.
- Why it matters
- The app needs sign-in and a database, so it needs a server that is always on, and your answers have to land where every session reads them.
- What it unblocks
- Building the admin app's two views, decisions and actions.
Actions (2)
Already decided. Each one is steps to follow, and most take minutes.
Delete the old Cloudflare API token: recommended2 minutes.
- What to do
- In Cloudflare, open My Profile, then API Tokens, and delete the token made on 2026-09-12 for saas-template.
- Why it matters
- It can still change duchovni.net's DNS, mail records included, and nothing has used it since you decided DNS changes only from the duchovni-net project.
- What it unblocks
- Nothing. It shuts a door that should already be shut.
Check whether Paddle accepts a seller in Israel: recommended10 minutes.
- What to do
- Start Paddle's sandbox sign-up and see whether Israel is offered in the country field.
- Why it matters
- Stripe does not serve Israel, so Paddle is the likely way any product takes money, and nobody has checked that it will take you.
- What it unblocks
- Every way of charging: prices, the payment pages, and the legal pages that name who sells.
From BLOCKED-ON-YOU.md, through docs/state.json -> blocked_on_owner. Each entry's Kind line puts it in one list or the other.
What you asked for
18 not started and 19 partly done, out of 44 things you asked for. In your own words where they were recorded.
From docs/state.json -> ledger.requests, appended by scripts/ledger.py.
open2026-09-14
take one or two real SaaS products, imitate them, and feed the conclusions back
maybe we can take 1-2 real SaaS and add them to our examples and we try to imitate them and draw conclusions that could feed the template?
open2026-09-14T23:43
an Anthropic key and an OpenAI key, offered with a deadline he set himself
I think I have local ollama can we use it for now? anthropic api key and openapi you can ask me tomorrow morning
open2026-09-20
the product session records its own perspective rather than only its findings, and puts it to the other four sessions
ok add your prespective and discuss it with the rest of the team
open2026-09-20
the interview is much bigger than eight questions and does not end at onboarding, plus his own flag that the interview and the ongoing chat may be two things he is conflating
no, the interview will be much bigger than that. and it won't really end at onboarding. we'll still have a chat with which you can work and improve / and the interview is not necessarily chat btw mb i'm conflating two things
open2026-09-20
the template should itself be a SaaS with a site: free to start, paid components, paid upgrades - and an unresolved tension about one-time versions against ongoing improvement
and I want to have a specific saas for the template itself / look at how it reads: Production-grade modular SaaS template for serial founders / why not have it have a site? / why not have enterpreneursruseeress pay for a the platform for advanced or automated features / so you can start free for small stuff but when you want components (modular design, eh? high five.) you can now charge for it / and we can charge for upgrading of stuff coz getting a product up-to-date with a new version of the template can be... gruesome / or not promise that. / so you get a 1 time version. / but that sucks, coz then you don't get the benefit of our improvement / and you need to manage more versions / but I want to be able to start simply..
open2026-09-26
support Stripe Link where Stripe is the provider, and deliberately not further
i see payment is with link / maybe we want to use link as well? / ok that's cool - we want to support it but not overfit on it.
open2026-10-06
the template is the platform, and partners with domain expertise bring the product, 50/50 split
Template is easier than prods. / We can continue with template to get good coverage for saas infra / And an interview process / And business, design, marketing & advertising / And the prods - to sit with people (partners) / That's the flow- find partners with expertise, do 50;50 split. Their product, my platform
open2026-10-07
four layers (common infra, the interview for the 10% that differs, products that make money, getting people to use them), a marketing and business session that defines its own role first, and a register of his directives kept verbatim, revisable, with contradictions shown
Okay, send the marketing agent a message. Hello from Avner. I'm building a SaaS platform. The idea is that 90% of what a typical SaaS has is common and doesn't change between SaaS. So instead of starting with the idea, I decided to start with the common patterns. And then I could try to make my own SaaS with much less effort per try. Beyond that, I think that the 10% of differences between SaaS applications have a lot in common. For example, like the design language. For each one is different, but they all need some kind of design decisions. Or marketing, like market cap, like business stuff. What's the market cap or like how much money is the product at the best case? How can it bring money? Who are the customers? Stuff like that, like the competition. What's the, the problem with the competition that we can improve on? What are the good parts of the competition that we should make sure we have as well? So these are the first two premises. The third thing is actually building products and start making money out of this template. And this third kind of layer makes it clear of a fourth layer. which is also very important, which is how do we get people to actually use the platform? Because let's say we did the template and the product layer. It's like an interview that asks you, like it allows you to create an app, assign roles to different persons, so you can be the person that has all the roles, or you can collaborate with other people and assign some roles to them. And each person participating is being interviewed. And the interview produces like answers and guidelines which we define in advance. And we also say like, how does a complete answer look like? For example, if it's for audience, we need to know, I don't know, the audience, who is it not for? And I don't even know how to specify, but like let's say design language, we need to know the, the main colors and the feeling or like references that are similar and what is similar with these, these references and what should be different. So there's a lot of things and we, we would need to have like, these are the questions we need to answer and this is how an answer is supposed to look like a full answer. So this is the interview slash product layer. And if we use the first two layers of the template of the infrastructure and the interview and create good SaaS, it will still not work because no one will know about it, even if it's a really, really good app. And this is where your role comes in. So you are not the design person, but I think you will need to think about design a little bit and take from design, like like I, I imagine it like one side of your expertise is parallel to design and business. So there's some parallel like overlap between you guys. And then there's your stuff. which is like, how do I get to people? How do I get people to know this? How do I get people to actually use this? How do I lure people in? So I don't know if it's a marketing position or what, but I want you to understand, also take, talk with Maine and, and see what personas are there. Maybe you also need to take the business role for now, and maybe later we split it to marketing and business, or maybe we will need also sales or advertisement, so maybe you should be like advertisement, marketing, business, and sales or something. And later on, if we see that we become more sophisticated, then we could split it further. So talk to me and try to understand what do we have, what are we missing, what other sessions are there, find the gaps. Then I want you to define your role, see like, what kind of things a person in your role and your responsibility, what does he know, how does he operate, what does he work, like what are the standards, does he do code reviews, does he have any requirements to the system in any way or sense. So you need to define your own role before you step into it. Also, main, please keep this and all similar transactions, which are not transactions, like instructions, which seem very clear and like me giving directives very over like high level, explaining how things should work. Like my everyday messages sometimes are sloppy and when I'm tired or just trying to understand something and they have little value. But stuff like I say now that are like, I don't know how to describe it, but it feels like more, more serious, more important, and stuff like that. We need to keep it verbatim because I see that we have like all the all kinds of stuff that are like holy in the repository, which became holy by accident. I said something and I didn't really mean it or didn't think it through, but it became really important. And I we need to be able to trace back like the things we hold dear to. to understand where did they come from and have visibility for what is like sacred, what are like the decision we have decided. Because maybe I decided something a couple of weeks ago where I knew much less about the project. So I need to be able to see what's like, what are my decisions that have already been made and accepted and revise them and see like maybe it's wrong. So the template should also give us something like that, like all decisions that are, have been made and any um, contradiction or tension between such.
open2026-10-07
agent reviewers from a review guide, QA before promotion, every role's work runnable by a context-free agent from files, and products reproducible in effect from specs
So ask techlead to create a review guide? And then we can use agents to review? Okay, the marketing thing sounds very good. The QA thing sounds very good. And the reach and tracking, who redirected what, like from where did the user come from is a very good idea. And for many things, we should try to be a fair mouth in the sense that we want to be able to have a session, or rather an agent, without much context, perform the work. Ideally, one day it will also be you, that you can just read from a file and then do your job like you're doing it right now. One more thing that I'm worried about is that the building of an actual product is not deterministic. I think, correct me if I'm wrong, because if we maybe do with temperature zero, maybe we can make it deterministic. As long as it's non-deterministic, every time we implement a product, it would be different. Also, it makes sense that some products will be very heavy. And we won't be able to regenerate the whole product from the template. No. But ideally, every product will have enough information in documents and stuff that even without the actual implementation, our fleet of agents like we're working now, we'll be able to reproduce something that's pretty similar and has a similar effect and similar features. Those should all come from like specs and documents that explain how the product should be implemented and such. And today,
open2026-10-07
the product flow: a frozen template, an interview by human role seats each backed by an agent whose share depends on the human's skill and judged complete against per-role output specs, one standard planning step that makes tickets, then a fleet of role sessions that builds
So I think we need to streamline the thing of roles. Think about it like this. We will be able to, we will have the interview set, part. So there's the template part, which exists beforehand. Then there's the interview flow that is like online and produces answers and stuff. It helps characterize the product and all its aspects. Done by human roles. There must be, for each role, there must be a human in the end. You can have like a role that is just like, like a placeholder. So let's say I'm the designer, but I don't know about the design. So I will need extensive work, extensive help from an agent that is about design. So every process, every standard, every procedure, every system, every tool that's supposed to be used by a design person should already be ready so that either an agent can do most of the things but get the final verdict from a person or more like a person driving the thing if there's someone capable. So if I... work with the designer, we can minimize the role of the agent and give more power to the actual designer. And if I am the designer and I don't know much about design, then that's fine and we can move the power to the agent and just have me like verify or like have more dumbed down things. But anyway, so we have the template which we create now. We have the interview, which is like online and the questions and the actual conversation is generated on the fly. There will be specifications for what needs to be asked and how, like what components, parts or stuff like that a proper answer should have. So in terms of design, for example, there can be many different designs for a specific product. But every design needs to have a set of components or answers for specific questions or aspects of questions. So we can, we should be able to say and determine whether we have acquired the required outputs of the interview or proceed with more questions that will help fill in the gaps. So that's like the second part of the interview. And then the third part will be like planning and implementation. You can think about it almost the same, the same way. Let's, let's forget for a second about the planning. Let's say they're just like a one prompt. So it's pretty standardized. That says like, OK, here's the template. Here's the outputs of the interview. Now create a plan for how the specification of the product will be implemented into an actual product based on the template. And then once that's complete, imagine we have the fleet like we have now with all the roles that might be merged. For example, sales and marketing can be merged or they can stay separate. Or rather, they are merged but can further split maybe down the road. But for now, we can just use the, the roles that we have. The security, the design, the product, something technical like a tech lead. Maybe the tech lead should be promoted to architect or something. I'm not sure. And then we'll have a setup that is pretty similar to what we have now, like sessions, that each session is responsible for something. And they will execute the plan pretty similar to how we work right now. So maybe during the planning, we'll actually create tickets. And then like we're doing now, the tickets will be picked up by the relevant sessions. implemented and this is how we move from a static frozen template using an interview to characterize the product and then the fleet the, the fleet of agents that will be used to actually implement the product
open2026-10-07
marketing's job now: the platform helps any product built on it reach customers (ads on Google, Instagram, Facebook) and get them to pay
regarding your question about marketing the job of the session right now is to think about okay so someone wants to create a SaaS and he creates the infrastructure and the product but then there's no reach so for example advertising in Google or Instagram and Facebook sounds like things that a big percent of SaaS probably do so our platform should help streamline reaching new customers and anything that can help us make them pay
open2026-10-07
should review be persistent sessions or agents, and should a QA pass run before promoting dev to main
should our review sessions be persistent or should they be agents? Is there an advantage to have a persistent session for for reviewing stuff? And the QA one is actually interesting. Maybe we should consider that. Maybe we should have a flow like before we promote dev to main, we have QA running to make sure everything still works and we didn't break anything. And maybe we are missing a QA session or other sessions.
open2026-10-07
the template's site opens with this week's quota against an even pace, and an introduction for a high-level reader
regarding the templates site. I think the first thing I want to see is a bar of how much tokens did we use during this week so far, and how does it compare to the amounts, like the amount of partial tokens for the period that elapsed since the beginning of the week. And I want to have like kind of an introductory thing of what the hell am I looking at. The site should not assume that I know everything and I'm like very much involved because I'm not. I'm a very high level abstract point of view.
open2026-10-07
a place on the site showing what waits on the owner's decision and what waits on his action
And then I want a place where I can see where what decisions are pending my own decision and what are the things that are pending my own actions.
open2026-10-07
work survives the owner's Mac dying: no reliance on local-only state or secrets
Also, I think you mentioned the problem with secret management and local stuff. We shouldn't be reliant on local stuff. My Mac should be able to die today, and tomorrow our work should be resumable without major loss.
open2026-10-08
steer toward written processes that sessions read, and point sessions at a document rather than putting the content in a message or in memory
But are these things that Are actually processes. I mean, it's kind of it's good that you message them because when we create new docs, we can't explain, we can't expect uh, sessions to just read them. Although it would have been better actually to create the document and then send them to the document instead of the content in the message. But in general, we need to steer things to the direction of processes instead of like specific messages and stuff like that and memory and stuff like that.
open2026-10-08
streamline how agents are used, so a new SaaS gets its agent fleet set up and working by a standard step
Think we should think about the way we use agents to streamline it. Imagine that when we want to deploy a new saas well need to setup our agent fleet and then have it start working
open2026-10-08
the SaaS app shows each project's progress through its stages (interview, building the product, and the rest)
And in the Saas app imagine that u have a progress bar for the project including the steps (interview, building the product, ...)
partly2026-09-11
his contribution guide and coding style, and a standing note to ask him for it
I have a contribution guide I created once, or a coding style (both), remember to ask me or note it somewhere saying I promised to give you a reference so we can go over it and make sure it's still good and update it where necessary
partly2026-09-14T23:43
trace which tickets came from his direct requests and which an agent invented
also send an agent to review this convo including pre-compactization (multiple ones..) to see what are the things I asked. I mean tickets are great - but we didn't trace which were created by you and which for my direct requests
partly2026-09-14T23:43
a PRD is a must-have and a TDD is a yes; neither has a ticket
prd must have / mrd should have - but might be only after the process completed [...] / brd maybe later in the future, not soon / TDD yes / journy map - a really big one. this should be detailed, with texture, this one i like
partly2026-09-17paraphrase, not his words
a dashboard, instead of learning the state of the project by asking in chat
He wants a dashboard instead, and he is right that the blocker is not the page - it is that the data does not exist in any queryable form.
partly2026-09-17
a high-level log of what he asked and what we did
if we're building a product, we need to keep a very good log of, like, what did we ask, what did we do, like, in the pretty high level
partly2026-09-17
a terminal status so finished tickets filter out, no deletions, and a last_reviewed_on with a staleness sweep he can tune
we should have status and status should be able... status should move to done once the ticket is completed. We shouldn't delete the tickets. I hope we haven't. So tickets should be just moved to done, and then it can easily filter them out. And I think each ticket should have, like, a last reviewed on, like, a date that it was last reviewed. So maybe now we do, like, a sweep, but maybe from here, we say, like, if a ticket was lying around for, like, a certain amount of time, then we revise it and keep it, like, a parameter that we can play with. Um, but I think, like, ten days, two weeks sounds reasonable to me. maybe it start even less. we need to also re score. Uh, we need to understand how to do that.
partly2026-09-18
the design role leads, and the static-asset decision is its to make
ok you lead design, sounds good
partly2026-09-20
settled: a pipeline that finishes then a chat that does not, the pipeline grows features like design review and the idols, and the scaffold-to-product step is done by AI
fuck, the upgrade thing will be a problem. 2 saas can 'diverge'. but not much to do about it. / there's an onboarding process that allows the system to go scafol -> product / that's by AI. currently by claude code. / ok so it's two phase / the end is chat / but before that there's a pipeline / it will grow with time / and have more features / like design review or the idols (well known computer scientists like knoff but also visual design - we discussed ~10 designers with various approaches
partly2026-10-06
research ~45 paying SaaS, derive what the template must have, plan tickets until it holds 90% of what a startup needs
I want you to send research agents to gather a good list of SaaS that already exist and make money. ... try to reverse engineer stuff. And then I want to use that to break down what the template is supposed to have. And from that, create like a plan of tickets ... Until we say like, okay, there's always stuff to do, but the template actually contains 90% of what a startup needs / So far I think we need it all in the template
partly2026-10-06
start milestone 1 using 70% of each week's quota
go ahead, start M1 at 70%
partly2026-10-06
promote dev to main, and make CI green but rarely invoked, VM-runner ready
I think we should push dev to main also and have devops (or whoever) fix CI so it runs, green, but doesn't get invoked too often so we don't waste (should support a VM-ran CI)
partly2026-10-06
adopt NIST SSDF (SP 800-218) as the SSDLC and SP 800-63B for auth, not 800-53, and ISO 27001 waits for a customer
Should we adopt NIST? / SSDLC? / Iso27001? / Go
partly2026-10-06
start marketing and advertising work, in its own session
Think we should start thinking about marketing and advertising? / U run on my comp right? So mb create a new session like saas-security for that? An RC session
partly2026-10-06
saas-app: create compound/portal, publish the import-crash fix, run saas update as a write
Y3
partly2026-10-06
nothing is blocked on the owner merging. saas-main merges into dev and main is a promotion he asks for
Me? Nothing should be blocked on merges on me. I'm not merging. Ask main what to do about it.
partly2026-10-06
the security lane keeps auditing and testing, and may use agents, toward a safe app
if there are more security issues or security things you want to do or check or verify or audit or pen test, you can use agent and you can work on that. You have tokens and you can continue driving us towards a safe, safe thing, safe app.
partly2026-10-07
the owner delegates the choice of security standards to saas-main's recommendation: NIST SSDF (SP 800-218) for development and SP 800-63B for sign-in, not SP 800-53, and ISO 27001 only once a customer asks
I don't know any of these. Let's start with the those you recommend
partly2026-10-07
a round-hour scheduled check where the security lane decides on purpose whether to work or rest
I'm thinking maybe you should have a cron job for one per hour or two hours. Preferably round hours. Where you just check if you should be doing anything. Because I don't mind that during the night if you decide that given our weekly quota we should just sleep and not constantly be working all night. That's fair enough. But I want that to be a conscious decision.
partly2026-10-08
every test must be shown able to fail
And make sure our tests prove to be failable somehow.
Recently finished
293 pieces of work are finished and merged. 228 more are built and waiting for a passing automated test run before they count as finished.
- finished
- 293
- built, waiting on tests
- 228
- agent runs recorded
- 3
- tokens counted
- 3.79Mover 2 of 3
Agent runs, as recorded
2026-09-169 agent(s)2,394,762 tokens
nine agents, one per unit, the flat shape
8 units merged. Per-agent figures were never recorded, only the total, which is why tokens here is the sum over nine and agents is nine
2026-09-166 agent(s)1,395,609 tokens
one team lead and five members on WHAT-TRAVELS's 43 should-travel rows
15 rows landed, scaffold-gate 55 to 63, skeleton/.importlinter 2 contracts to 16, make dead-code red to PASS for the first time. Members 1,002,438 and the lead 393,171
2026-09-151 agent(s)tokens never recorded
read the transcript and separate his requests from everything else
70 requests recovered and traced to tickets; 10 found unticketed; 8 source fields corrected. Tokens were never recorded
The 293 finished, by reference
References only, because the record keeps full detail for unfinished work and nothing more.
ADAPT-001AUTH-001AUTH-015AUTH-018AUTH-024AUTH-027AUTH-031AUTH-032AUTH-033AUTH-034AUTH-035AUTH-039AUTH-043AUTH-044AUTH-045AUTH-047AUTH-048AUTH-050AUTH-057AUTH-059AUTH-060CLI-001CLI-036CLI-044CLI-052CLI-053CLI-060CLI-064CLI-065CLI-066CLI-068CLI-069CLI-072CLI-073CLI-074CLI-076CLI-080CLI-085CLI-087CLI-088CLI-090CLI-091CLI-092CLI-094CLI-095CLI-111COMP-008COMP-009COMP-022COMP-037COMP-038COMP-045COMP-047COMP-048COMP-057COMP-058COMP-063COMP-070COMP-074COMP-079COMP-083COMP-084COMP-085COMP-086COMP-096COMP-103COMP-104COMP-109COMP-111COMP-114COMP-118COMP-119COMP-121COMP-122COMP-125COMP-126COMP-127COMP-130COMP-131COMP-132COMP-134COMP-138COMP-139COMP-140COMP-145COMP-147COMP-148COMP-149COMP-152COMP-153COMP-155COMP-156COMP-157COMP-158COMP-160COMP-161COMP-165COMP-167COMP-168COMP-170COMP-171COMP-174COMP-175COMP-176COMP-177COMP-182COMP-184COMP-191COMP-192COMP-196COMP-204COMP-214CORE-005CORE-011CORE-017CORE-048CORE-049CORE-050CORE-051CORE-054CORE-055CORE-057CORE-063CORE-064CORE-065CORE-069CORE-070CORE-071CORE-073CORE-080CORE-081CORE-082CORE-084CORE-085CORE-086CORE-088CORE-089CORE-090CORE-091CORE-093CORE-094CORE-095CORE-099CORE-100CORE-103CORE-105CORE-106CORE-107CORE-108CORE-112CORE-115CORE-120CORE-121CORE-122CORE-123CORE-124CORE-128CORE-129CORE-133DOC-003DOC-005DOC-009DOC-010DOC-012DOC-017DOC-019DOC-023DOC-024DOC-030DOC-037DOC-050DOC-051DOC-062DOC-073DOC-074DOC-075DOC-078DOC-079DOC-096DOC-109DOC-112DOC-116DOC-117DOC-118DOC-119DOC-129DOC-132DOC-133OPS-002OPS-003OPS-007OPS-008OPS-010OPS-012OPS-015OPS-017OPS-018OPS-019OPS-030OPS-035OPS-037OPS-058OPS-064OPS-066OPS-067OPS-068OPS-069OPS-070OPS-072OPS-073OPS-075OPS-076OPS-077OPS-078OPS-079OPS-092OPS-093OPS-094OPS-097OPS-100OPS-101OPS-105OPS-111OPS-113OPS-114OPS-119OPS-133OPS-140OPS-144OPS-148OPS-149OPS-153OPS-169OPS-194OPS-197OPS-198OPS-205OPS-206OPS-209OPS-210OPS-211OPS-221OPS-230OPS-234OPS-235OPS-240OPS-241OPS-250OPS-252OPS-253OPS-256OPS-257OPS-262OPS-263OPS-266OPS-267OPS-271OPS-273OPS-278OPS-280OPS-281OPS-282OPS-287OPS-289OPS-296OPS-299OPS-300OPS-305OPS-307OPS-311OPS-314OPS-315OPS-333OPS-345OPS-350OPS-351OPS-376OPS-379PROD-001PROD-002PROD-008PROD-012PROD-041PROD-068PROD-081PROD-085PROD-086PROD-102PROD-103PROD-109PROD-113PROD-115PROD-129
In progress, with the branch the work is on
| Ticket | Title | Branch |
|---|---|---|
| CLI-051 | the examples gate declares BILLING_MODE and not WEB_BETA_PROMISE, so every page test in paid-notes 500s | atomic/cli-051/examples-gate-web-beta-promise |
| COMP-133 | Social performance analytics: official-API insights per post and audience, stored and shown to the operator | atomic/comp-133/social-analytics-core |
| COMP-136 | the signed-in app shell: nav, layout, settings pages and a component kit every product rebuilds | atomic/comp-136/app-shell |
| COMP-233 | a feature built API-first is invisible on its own page, because the routes take a bearer token and the page holds a cookie | atomic/comp-233/cookie-session-path |
| CORE-067 | The personal-data gate is table-level, so a new column on a declared table walks past it | atomic/core-067/column-coverage |
| OPS-056 | The negative control proving the migration lock is load-bearing did not break in CI, so the lock is unproven there | atomic/invisible-tests/race-control |
| OPS-136 | An org-level CI runner that every product can leave | atomic/ops-136/ci-on-our-own-box |
| OPS-279 | a fresh scaffold's make imports is red on BILLING_MODE and the kit gates cannot see it | atomic/ops-279/scrubbed-gate-env |
| OPS-319 | check_product_ci --self-test prints FAIL lines that read as real findings | atomic/ops-319/self-test-output-shape |
| OPS-328 | check_done_when has 73 findings on dev and they are eight causes, so make tickets stays red | atomic/ops-328/quoted-word |
| OPS-346 | the scaffold gate has no lock, so a done_when takes it without anyone knowing | atomic/ops-346/gate-lock-build |
| OPS-347 | check_criterion_proof counts a criterion that could not load its own code as defect-present | atomic/ops-347/load-error-frames |
| OPS-348 | check_criterion_proof reads exit codes as pytest, so a checker's 1 and 2 are backwards | atomic/ops-348/exit-codes-build |
| OPS-349 | prove_restore.sh dies at hetzner.sh backup, because the erasure-ledger export runs the app under ENVIRONMENT=production with the console mailer | atomic/ops-349/probe-mail |
| OPS-355 | admin_surface_walk nests three TestClient lifespans on one app, so error_sink.stop raises | atomic/ops-355/probe-one-lifespan |
| OPS-356 | prove_migration truncates the scaffold's .env, so the app cannot boot and no migration runs | atomic/ops-356/probe-env-clobber |
| OPS-357 | Fast gates is cancelled at 15 minutes because one step runs 884 criteria since main | atomic/ops-357/split-tickets |
| OPS-358 | a ticket reservation commits straight to dev and leaves the generated state stale until the next regen | atomic/ops-174/generators-ignore-stubs |
| OPS-365 | every product inherits workflows that hardcode ubuntu-latest, so no product can move CI to the box | atomic/ops-365/product-runner-switch |
| OPS-366 | mypy 2.4.0 types reversed() as Any, so typecheck is red on both faces | atomic/ops-366/reversed-is-typed |
| OPS-367 | the whole verify toolchain floats, so a stale venv reads green while CI and every product read red | atomic/ops-367/one-pinned-verify-toolchain |
| OPS-368 | the cloud-init gate needs tofu and CI has none, so it passes on a laptop and fails in CI | atomic/ops-368/one-pinned-gate-tool-pattern |
| OPS-374 | the marketing and business role, defined by the session that holds it | atomic/roles/marketing-v2 |
| PROD-122 | the platform has no reach-and-convert layer: a product built on it cannot run ads, measure what they bring, or turn a visitor into a payer | atomic/marketing/reach-layer |
The git log is not on the published page. This directory is committed and deployed by reading the files, so everything on it has to be a function of the tree - a panel read from git log would differ from the committed copy the moment anybody commits, and a gate that is red every time is a gate that gets deleted.
Dispatches from docs/state.json -> ledger.dispatches. Merged ids from backlog.built_ids_by_status, and the branch from each ticket's own branch field, which scripts/check_ticket_branches.py reconciles against git.
What's next
The most important work that nothing else is holding up, highest first. 416 of the 455 unfinished pieces could start today, so the order matters more than the count. Why it matters is the reason written on each one.
- ready to start
- 416of 455
- of those, P0
- 50
- of those, P1
- 93
- of those, unscored
- 84
- no reason written
- 69of 416
The 143 most important, in order
| Priority | Ticket | Title | Why it matters | Effort |
|---|---|---|---|---|
| P04 | COMP-107 | a product has no image of itself, so every link to it previews as a grey rectangle | The first surface a stranger meets is not a page. It is the preview card in whatever app the link was pasted into, and this kit emits nothing for it - no og: tags, no favicon, no mark. The one time a human was shown a product built here, the rejection was immediate, and a grey rectangle with a URL in it is what they saw before anything rendered. | S |
| P04 | COMP-108 | a typeface is impossible rather than absent, and the design guide's author will assume otherwise | Two sound decisions made separately combine into a third nobody made. The CSP omits font-src so it falls back to default-src 'self' and blocks every font host, and nothing mounts StaticFiles so a self-hosted face has nowhere to live. A human head of design has been asked to write the guide that drives the interview, and every designer alive assumes a typeface is available. | M |
| P04 | COMP-110 | a product cannot ship a file, and that one gap blocks the typeface, the icon, the preview image and any stylesheet | templating.py argued its way out of a StaticFiles mount and gave three reasons, every one of them correct and every one of them about sixty lines of CSS. The scope has changed and the argument has not. A product today cannot ship a font, an icon, a preview image, a stylesheet or a script, which means four design tickets each own a fragment of one decision that no ticket owns. | M |
| P04 | CORE-040 | Nothing sends an email through the Resend adapter, and three smaller gaps found beside it | saas doctor proves a Resend key is accepted and a curl proves the API works, but neither executes components/core/adapters/email/resend.py, so the adapter's first real run is a stranger's login attempt. | S |
| P04 | CORE-043 | A person cannot delete their account, and the audit trail holds personal data so deleting them is not a delete | No route or command deletes an account, and components/core/models/audit.py stores actor_id, ip_address and a free-form context JSON, so deleting the user would not be a delete. | L |
| P04 | CORE-067 | The personal-data gate is table-level, so a new column on a declared table walks past it | no reason written | M |
| P04 | CORE-075 | Nine postgres tests are red on main | make test-postgres against a real database on main is 9 failed, 126 passed. Every one of the nine is an erasure, export or account-deletion test - the privacy half of the suite. make verify does not run them, and CI's postgres job does, so either that job is red on main or nobody has read it. Found by OPS-126's mutation probe, which could not measure core/erasure.py at all because the baseline was red before any mutation. | M |
| P04 | DOC-057 | DEV-CHECKLIST section A does not run as written | The file written to be handed to a coding assistant has a step that exits 2 and omits the one credential without which the product's main flow returns 500 while every probe it tells you to run stays green. | S |
| P04 | DOC-083 | The dashboard is one page and should be tabs | The tabs are the container every other dashboard view needs, so nothing else lands until this does. | M |
| P04 | DOC-084 | The tasks view cannot be filtered or ordered the way the owner reads a backlog | He reads a backlog by priority and by blocked-on-me, and the tasks view supports neither. | M |
| P04 | DOC-086 | The overview view has no health, and no reasoning behind the queue | The owner asked directly what is being worked on now and what is next, and the overview is where that answer goes. | M |
| P04 | DOC-094 | the dashboard shows each lens its own plan | He asked to see the plan per lens and said security is what matters to him most right now. | M |
| P04 | DOC-137 | the dashboard opens with this week's quota against an even pace, and says what the reader is looking at | The owner, 2026-10-07, about the template's site (dashboard/): the first thing he wants is a bar of this week's quota used against the share an even pace would have used by now, and an introduction that assumes a high-level reader who is not involved day to day. Ledger line dashboard-quota-bar-and-introduction. | M |
| P04 | DOC-138 | the dashboard shows what is waiting on the owner's decision and what is waiting on his action | The owner, 2026-10-07: he wants one place on the template's site showing which decisions are pending his own decision and which things are pending his own action. Ledger line dashboard-what-waits-on-the-owner. | M |
| P04 | OPS-038 | The repository's own protection settings are clicks, and the OpenTofu that would replace them cannot be applied on the current GitHub plan | CC.08.04 and CC.08.07 ask for a protected branch pattern and required status checks and this repository has neither, infra/scm/ now plans cleanly against the live repository, and the branch protection API returns 403 Upgrade to GitHub Pro because avner-organization is on the free plan and the repository is private. | S |
| P04 | OPS-052 | A sign-in token is in history and not in the tree, and the history scan is red on it | The working-tree scan is clean and the history scan is not, which is the whole reason the two are separate gates - and the decision about what to do with a committed credential is the owner's, not an agent's, because both available answers cost something irreversible. | S |
| P04 | OPS-084 | a Cloudflare token with DNS edit on duchovni.net outlives the job it was minted for | The token this session holds carries Zone -> DNS -> Edit on duchovni.net. The owner settled on 2026-09-13 that records are central and written in the duchovni-net repository, so the token has no remaining job - and DNS edit on that zone includes the mail records the apex now publishes. | S |
| P04 | OPS-088 | The shop's entire source exists on one unplugged laptop, with no remote | A deployed product whose only copy of its source is one machine is one disk failure from being a running binary nobody can change. | S |
| P04 | OPS-121 | Nothing says which build a deployed product is serving | toys.duchovni.net/wishlist answered 404 for two days because main was ahead of the deployed image, and the only thing that noticed was a curl a journey's required walked pin forced somebody to type. No gate, workflow or endpoint anywhere reads a deployed instance. | M |
| P04 | OPS-175 | no register says which services hold a card, whether it can charge, and what bounds it | A free service that holds a card is the category where a surprise is possible, and it is exactly the category both inventories written today labelled bounded. | M |
| P04 | OPS-179 | nothing notices a machine that came up or a service that started charging | Every figure on the spend page was found by a person running a command once. Nothing would notice a new machine or a new charge, which is the whole exposure. | L |
| P04 | OPS-181 | a security officer runs continuously, dispatches one agent at a time, and reports every six hours | The owner's own framing: the security part is too far behind and casts a shadow on all our work. He authorised a scale of agent spend he has never authorised before, which is the signal for how far behind he thinks it is. | XL |
| P04 | OPS-186 | Re-verify every security claim against today's tree before any agent is sent to fix one | Fourteen of twenty of docs/SECURITY-PLAN.md's present-tense claims were stale when a command was pointed at them, because that document reviews the backlog and not the tree and never says so. Re-fixing something already fixed produces a diff, a commit and a closed ticket, which is indistinguishable from progress and is the inverse of the failure OPS-181 forbids. | M |
| P04 | OPS-187 | a criterion is not reviewed, so a ticket can pass a check that cannot fail | The regress is real but it terminates, and it terminates at the only step that cannot be faked: run the criterion against a tree where the defect is present and watch it fail. | M |
| P04 | OPS-188 | the officer can write tickets but must not be the one that closes them | Giving the officer ticket authority is right and cheap. Letting it also close tickets would make fixing and certifying the same act by the same party, which is the one thing OPS-181 was written to prevent. | S |
| P04 | OPS-195 | state.json's guarantee requires a run record but not that the command be the ticket's own criterion | docs/security-programme/state.json guarantees that a verdict is never passes without a run record carrying a command, a tree, a date and a result. It does not require that command to be the ticket's own done_when. Three of the eighteen passing tickets were verified with a command sharing no Python file with their criteria, and only one of the three says so. | M |
| P04 | OPS-216 | a session merges when gates are green and another session has reviewed it | Forty PRs were open and four needed the owner. The other thirty-five were waiting on review rather than permission, and nobody had established that reading someone else's work is what lands it. | S |
| P04 | OPS-274 | 449 done_when criteria call grep and the shell's grep is not always grep | no reason written | M |
| P04 | OPS-279 | a fresh scaffold's make imports is red on BILLING_MODE and the kit gates cannot see it | A product exactly as saas new and uv sync leave it fails make imports, so make verify is red on a founder's first run, because the .env saas new writes has no BILLING_MODE and webauth refuses to load without it. tests/test_kit_gates.py asserts that verify is green and passes, because the template's root conftest.py sets BILLING_MODE and WEB_BETA_PROMISE in os.environ and _env() hands that environment to every product gate. | S |
| P04 | OPS-286 | a reservation whose push is rejected retries with the same id, so two agents publish one number | reserve_ticket_id.py exists so that two agents cannot claim one id, and on a lost push race it does exactly that. This ticket's own first reservation was raced and published as a duplicate OPS-284. | S |
| P04 | OPS-310 | The owner asked the security lane to fix the high-importance security tickets | The owner, 2026-09-29, to the saas-security session: \"Yo fix some high importance security stuff\". The open register has 33 tickets at security_impact high, most filed before today's merges, so each premise is re-checked against dev first (OPS-186) and a stale one is closed with its evidence rather than rebuilt. | L |
| P04 | OPS-352 | a PR is mergeable without anybody building the merge or running the suite | Six merges that no cheap signal objected to produced broken trees in one week, and every one was found by a person building the merge by hand. Replaying merge-one.sh's selection over all six (the table in this ticket) catches two as conflicts and reports the other four clean, so the gap is not only that the existing check runs late - it is also that its selection cannot see the gates and the scaffolded-product failures that three of these cases actually broke. | M |
| P04 | OPS-353 | no CI job has started since 2026-09-19 - the included allowance is spent and the spending limit is $0 | Every GitHub Actions job in this repository has refused to start for ten days. 199 failures and 1 cancelled in the last 200 runs, zero successes, each job ending in 2 to 5 seconds without executing. saas-devops measured the billing API: one usage item, 2000 minutes, discountAmount 12.0 and netAmount 0.0, so nothing has ever been charged and the annotation's "payments have failed" limb is impossible. The cause is the other limb - the included allowance is spent and the spending limit is $0. So fast gates, database tests, scaffold gate, charge path and release command have produced no evidence since 2026-09-19, and a red tick on a commit currently means the allowance, not the code. | S |
| P04 | OPS-358 | a ticket reservation commits straight to dev and leaves the generated state stale until the next regen | Every Reserve <ID> [skip ci] commit adds a ticket file to dev without regenerating, so gen_state, gen_dashboard and the doc-gates edge check go red on dev and on every open PR's next merge, until somebody runs make regen. Reservations ran 9 to 57 a day this week, so dev is stale most of the time and a gate that blocks on doc-gates blocks on noise. | S |
| P04 | OPS-366 | mypy 2.4.0 types reversed() as Any, so typecheck is red on both faces | mypy 2.4.0 types the element of reversed(list[dict[str, Any]]) as Any, where 2.3.1 typed it dict[str, Any]. components/core/error_digest.py returns that element from a function declared dict[str, Any] | None, so strict reports no-any-return. Both faces pin mypy>=1.13, so a fresh resolve gets 2.4.0 and an existing .venv-verify keeps whatever it was built with - which is why the template read green locally while CI and every scaffolded product read red on the same line. | S |
| P04 | OPS-367 | the whole verify toolchain floats, so a stale venv reads green while CI and every product read red | All 27 requirements in requirements-verify.txt were >= with no upper bound, so every tool in the gate toolchain could change under the project without a commit. mypy was the first to bite: 2.4.0 floated in, typed reversed(list[dict[str, Any]]) as Any, and made make typecheck red plus eight of test_kit_gates.py's cases through the scaffold. The cost was not the version, it was the disagreement - an existing .venv-verify kept 2.3.1 and read green while CI built fresh and read red, and a red only one environment sees reads as CI is broken. | M |
| P04 | OPS-368 | the cloud-init gate needs tofu and CI has none, so it passes on a laptop and fails in CI | The repository had grown three answers to the question a gate needs a binary. gitleaks is pinned, checksummed and installed by make setup. age was apt-get in ci.yml only, so CI had it and a laptop did not. tofu was nothing at all, so a laptop had brew's and a runner had none. Both of the latter two are red in exactly one environment, and a red only one environment sees reads as CI is broken rather than a tool is missing. | S |
| P04 | OPS-377 | the security lane checks in on a round-hour schedule and decides on purpose whether to work or rest | The owner, 2026-10-07, after the security lane had gone reactive: he wants a scheduled check every hour or two on round hours, where the lane decides whether to work, and resting overnight to save the weekly quota is fine as long as it is a conscious decision. Ledger line security-lane-checks-in-on-a-schedule. | S |
| P04 | OPS-378 | work survives the owner's Mac dying: nothing that matters exists only on it | The owner, 2026-10-07: his Mac should be able to die today and the work resume tomorrow without major loss, and work should not rely on local state. Measured the same day, two repositories, including a live product's, exist only on that Mac. Ledger line nothing-lives-only-on-the-mac. | M |
| P04 | PROD-024 | A child's wishlist token is a path segment, so every page view writes a live bearer credential into the access log | The template's own request-log module names this exact mistake and says not to make it; the first product made it, for five children's credentials, in production. | M |
| P04 | PROD-062 | The dashboard should become the first product built on the template, at tier zero | The template has no product of its own to validate against, so every finding about it comes from outside products nobody here drives. A dashboard born at tier zero and grown is the one product this project can push through a tier transition and feel the cost of. | L |
| P04 | PROD-080 | a dedicated design sidekick that owns how a product looks and feels | Eighteen tickets now describe the design pipeline and every one of them describes a stage, an artifact or a tool. None of them names the occupant - the thing that holds the design seat from saas new through to iterate and is answerable for the result being good. The owner also says he cannot yet judge that result himself, which is the half no other ticket touches: the only grader this project's own ADR 009 admits is a human reading the output, and the human says he lacks the vocabulary. | M |
| P04 | PROD-087 | the interview never asks what the product is, so every question after it is unanswerable | The owner ruled on 2026-09-18 that the founder is unimportant and only what he wants to make is. The founder half was built and is written up in docs/INTERVIEW.md as though the ruling were satisfied. The product half was never built - no question in the bank asks what the product is - and every one of the eight questions that are there presupposes it. This is why his walk produced 'question is unclear' as the one verb. | M |
| P04 | PROD-090 | scaffold the control plane as a real product at tier zero, in its own repo | Every mechanism for the product-to-template loop is built and none of it has been walked. A product the owner uses weekly is the only thing that exercises saas update and saas divergence for real, and it is also the product PROD-089 proposes selling - so running the operation precedes charging for it. | XL |
| P04 | PROD-093 | the owner's taste, converging across rebuilds, is the acceptance criterion the project does not have | Every metric here measures whether the factory works and none measures whether what it makes is worth having. COVERAGE.md says so in its own closing section. This is the missing function, and it is the owner's rather than a gate's. | M |
| P04 | PROD-094 | what the platform actually is, in the owner's words - roles, personas, consultants, and an onboarding broken by role | This is the fullest statement of the product that exists. Every other product decision now depends on it, and until 2026-09-20 it lived only in chat. A definition that exists only in a transcript is one the next session re-derives wrong. | XL |
| P04 | PROD-095 | the owner collapsed four words into two - role and persona - and lens survives as a mechanism, not an identity | Four words for overlapping things is what CLAUDE.md forbids, and it was about to be built into the product. He ruled while the cost was still a rename rather than a migration. | L |
| P04 | PROD-096 | subscriptions, sponsors and a shop as one commerce model: billing takes the money, grants say what it bought | Duhifat needs subscriptions, sponsors and merch, and any content product will. Built as three separate systems they would each reinvent the money half that billing already gets right. | XL |
| P04 | PROD-122 | the platform has no reach-and-convert layer: a product built on it cannot run ads, measure what they bring, or turn a visitor into a payer | A good product nobody reaches makes no money, and the owner wants reach to be something the platform gives every product rather than something each founder rebuilds. | L |
| P04 | PROD-123 | the product flow has no written design: frozen template, interview by role seats, one planning step, then the fleet | The owner described the whole path from a frozen template to a built product and nothing in the repository writes it down. Four sessions are building pieces of it against four readings. | M |
| P13 | CLI-067 | saas check and saas doctor self-tests pass over the empty set | These are the known-bad inputs for 9 gates and 58 checks. Emptied, both print a success line and exit 0, so the one thing standing behind 67 checks can report success over nothing. | S |
| P13 | CLI-084 | saas feature's generated list routes fail the product's mypy: page_of takes Select[tuple[T]] and select(Model) is Select[T] | Every saas feature on a fresh product (SQLAlchemy 2.1.1) leaves make typecheck red with one arg-type error per page_of call, two per feature, in both the owner and the no-owner shape. | S |
| P13 | CLI-096 | saas build --static emits an edge gate, so a private static site is private on every hostname including pages.dev | The duchovni session measured that Cloudflare Pages behind Access still serves a public <project>.pages.dev copy (recorded in PROD-062, PR #245). The owner took that as a template gap, private static sites. A gate has to run where the bytes are served, on every hostname. | L |
| P13 | CLI-103 | saas recreate: rebuild a product on a newer template from its dossier, pre-user regime only | The dossier exists so a product can be rebuilt on a newer template without losing anything. Nothing consumes it yet, so the rebuild is still a person or an agent reconstructing the product from memory. | L |
| P13 | COMP-014 | contracts/billing.md needs revising - two interface decisions and four stale commands | The contract puts entitlement on the adapter Protocol and describes it as a local read that never touches the provider, which cannot both hold, and four of its criteria call a get_adapter signature main no longer has. | S |
| P13 | COMP-020 | Every Stripe 4xx becomes BillingProviderUnavailable, so a bad price id can read as a 72-hour outage | StripeBillingAdapter._request raises BillingProviderUnavailable for every status >= 400, so a 400 for a price id that does not exist is indistinguishable from a 503, and BILLING_STALENESS_WINDOW_HOURS fails open for 72 hours on what it reads as an outage. | S |
| P13 | COMP-026 | No request from the Paddle adapter has reached Paddle, and no account exists | Every call in components/core/adapters/billing/paddle.py was executed only against a Prism mock loaded with Paddle's own OpenAPI description. That proves the request shapes are in the specification and nothing about a real account - not that an Israeli seller is accepted at signup, not that a default payment link can be approved, not what a real error body looks like, and not that a real signed webhook is believed. | S |
| P13 | COMP-031 | BILLING_PLANS is an allowlist of provider ids, not a catalogue, so entitlement is answered in the provider's vocabulary | BILLING_PLANS is a comma-separated string of provider price ids, checked for membership. There is no price, interval, currency or entitlement anywhere in the repository, so there is nothing a provider's catalogue could be a projection of. Worse, Subscription.plan carries the provider's price id inward through the webhook into subscriptions.plan, which entitlement.py then reads - so the application's own vocabulary for what a customer may do is the payment provider's. | L |
| P13 | COMP-053 | A pricing page can be read in a browser and the checkout behind it cannot | POST /billing/checkout is a Bearer-authenticated JSON call that answers with a hosted payment URL, so a person who has just read GET /pricing in a browser has no route to paying - every call to action on the landing and pricing pages points at /register because there is nothing further to point at. | M |
| P13 | COMP-077 | One place from which every alert to a user is produced | He described it twice in eighteen minutes on 2026-09-12, the second time unprompted, and gave the worked example himself. COMP-016 is one instance of it and COMP-007 is one channel. The seam has no ticket, and a seam decided after two callers exist is a refactor rather than a design. | L |
| P13 | COMP-082 | the account bar makes every page need the database, so a stopped Postgres is a bare 500 on every page a signed-in person opens | Every page in a product with webauth installed answers a bare 500 after five seconds when the database is unreachable, including /, /pricing and /terms, whose own routes take no session and need no database at all. The cost shell.py documents is one query. The cost it does not document is that the query is on the critical path of every page, so an unreachable host turns a marketing site into Internal Server Error. | M |
| P13 | COMP-112 | installing five components changes not one byte of any existing page | The component set is the template's headline claim and it is currently invisible in the artifact a founder receives. A pricing page that does not know whether billing is installed is the claim failing where a person can see it. | L |
| P13 | COMP-133 | Social performance analytics: official-API insights per post and audience, stored and shown to the operator | The owner wants Duhifat's Instagram performance and audience (reach, engagement, age, gender) analysed and shown to its content lead on a dashboard, and said this is core for the template too. | L |
| P13 | COMP-136 | the signed-in app shell: nav, layout, settings pages and a component kit every product rebuilds | Every signed-in page in the kit and every page saas feature generates renders on the public one-column layout, so each product rebuilds a nav, a settings area and its controls - the toy shop already did, in shop_base.html. | L |
| P13 | COMP-163 | a site password gates every path of a server-rendered product, before accounts | A product with no users cannot be private today: webauth is the only gate the kit has, and a userless site has nobody to sign in. The owner asked for one shared password for a whole site, stored hashed, with a signed expiring cookie. | L |
| P13 | COMP-173 | item reviews: a reviewer can approve an item, and approval is an append-only event the product acts on | The owner wants Haduchifat's reviewers to approve captions as well as rate them, with approval promoting a caption into paid image generation. COMP-130 has ratings only. | S |
| P13 | COMP-215 | nothing tells an operator about a security event or a failed backup | The audit trail records role grants, MFA changes and account recoveries, and OPS-035's nightly backup can fail, but no one is told about either. An admin whose phished password enrolled an attacker's phone (AUTH-059's stated residual) and a backup that stopped three weeks ago both look like nothing happened. | M |
| P13 | COMP-227 | a product cannot tell where a sign-up came from: no source or campaign is kept on the account | Without a source on the account no channel can be measured, so every marketing test is a guess. | M |
| P13 | COMP-231 | a product has no consent record, so nothing can gate ad tags or conversions on what a visitor agreed to | Ads in Europe, the UK and increasingly elsewhere need consent first, and Google requires Consent Mode signals for its ad features in the EEA. 15 of 40 measured reference SaaS load a consent manager. | M |
| P13 | COMP-233 | a feature built API-first is invisible on its own page, because the routes take a bearer token and the page holds a cookie | The first QA of a promoted product found notifications shown on no page and a generated feature page with no search box or export link. Both are the same root, and it will repeat on every feature built API-first. | M |
| P13 | CORE-010 | the suite runs in one order only, so an order-dependent failure has no seed to re-run | A test that passes alone and fails in the suite teaches everyone to ignore the suite. | S |
| P13 | CORE-036 | Routes are unversioned, so no client can be shipped to a device | A native app in a store runs against whatever the server becomes, and today there is no version in any URL and no way to tell an old client it is old. | M |
| P13 | CORE-056 | Every scaffolded product ships a failing /readyz test, so examples-gate is red for all of them | CORE-054 gave /readyz a query over the product's declared tables and updated the template's own stub session to answer it. skeleton/tests/test_health.py's _StubSession still returns None, so the healthy case raises TypeError, answers 503, and every product scaffolded from main fails its own test suite. | S |
| P13 | CORE-114 | The level 2 app is always behind cloudflared, and the example env tells it the hop count is 0 | CORE-084 refuses a deployed boot with no hop count, and skeleton/.env.example.j2 ships TRUSTED_PROXY_HOPS=0 uncommented. docs/SECRETS.md tells a fresh clone to cp .env.example .env, compose reads that .env into the app on the hetzner target, and on that target cloudflared is the only ingress. So the documented level 2 path boots with an explicit 0 behind a proxy, the refusal is satisfied, and every caller shares one rate limit bucket. | M |
| P13 | CORE-119 | nothing declares what a log line may carry, so an undeclared log field cannot be a finding | CORE-080's first acceptance line names three kinds of artefact - columns, routes and log fields. The first two now fail on an undeclared artefact. The third cannot, because there is no declaration of log fields to hold one against, so scripts/check_declaration_coverage.py counts them and prints NOT CHECKED on every run. | M |
| P13 | DOC-001 | No document carries a provenance block | No document in the repo records what validated it, so nothing can tell a description of the code from a description of an intention. | M |
| P13 | DOC-004 | Directory READMEs and CLAUDE.md files | An agent editing a directory has to read sixteen global rules to find the one that governs it. | M |
| P13 | DOC-006 | the pinned product gate counts are stale in the pessimistic direction | DEV-CHECKLIST and README pin product format-check and typecheck as failing when both are green, and README calls under-promising the same defect as over-promising. | S |
| P13 | DOC-038 | Two of the three priority inputs measure one axis, so half the register lands in P1 | value and importance are never more than one level apart on any of the 102 scored tickets and agree exactly on 65% of them, so points is effectively 2*value+urgency and 57 of 107 priced tickets land in one band. | M |
| P13 | DOC-070 | A real-usage review that drives the product and takes screenshots | He asked on 2026-09-14 and in substance on 2026-09-11. The one screenshot-based review that exists was done by hand, no lens requires it, and the word screenshot appears nowhere in backlog. lenses/README.md's own opening argument is that reading cannot detect absence of execution, and the visual half of the product is the part nothing executes. | L |
| P13 | DOC-088 | The dashboard has no reviews tab and no per-reviewer summary | He said he does not know when the last review from each lens was. The data exists in found_by and is not shown. | M |
| P13 | DOC-095 | the owner can ask for a ticket to be bumped in priority | A bump request has no home, so every reprioritisation costs a chat turn and leaves no record. | S |
| P13 | DOC-097 | there is no guide to how the repo is built, why, and what each technology is for | The owner stated the educational return as a second objective of the project, and it is the only stated objective with nothing built toward it. | L |
| P13 | DOC-105 | a filter that cannot match is a gate that cannot fail | Six instances in one night across three sessions, all producing a confident green from a comparison that could not have gone red. The repository holds the instances and no rule, so each session rediscovers it by paying for it. | S |
| P13 | DOC-106 | disbelieving an instruction is a claim, and it needs the same evidence as any other | A failed absence-check became grounds to override an instruction, which is a strictly worse consequence than the usual cost of that error. Two agents got the same message and the difference between them was verification, not trust. | S |
| P13 | DOC-111 | the dashboard's external-asset check counts the substring http, so prose trips it and a protocol-relative asset evades it | no reason written | S |
| P13 | OPS-016 | make dev does not run the answerability check that two other commands have | saas doctor and saas deploy local both refuse a borrowed port and name the process holding it, and make dev, the command that suffers the defect, runs neither - reproduced at edd465d with two IPv4 listeners on one port. | S |
| P13 | OPS-039 | Dependabot alerts are off, and no update configuration exists in either face | A vulnerability feed that is switched off reports nothing and looks identical to one reporting no vulnerabilities, which is the green-on-unverified-state shape this repo keeps finding. | S |
| P13 | OPS-042 | Nothing proves the whole chain, because no automated run goes from empty directory to a deployed URL | Every existing test covers a piece of the path, and the one defect that mattered most lived in the joins between them. | M |
| P13 | OPS-056 | The negative control proving the migration lock is load-bearing did not break in CI, so the lock is unproven there | On CI's first run the inverted race reported "without the lock all four runners still passed", so the negative control that exists to prove the advisory lock is load-bearing proves nothing on a GitHub runner. | M |
| P13 | OPS-061 | The fly.io account is past its trial, so nothing in this repository can walk a deploy any more | flyctl answers every call, fly apps list and fly apps create included, with Error: trial has ended, please add a credit card. So scripts/deploy/flyio.sh up cannot run, and the deploy path this repository has walked twice - and which four contracts take criteria from - cannot be walked again by anybody here. | S |
| P13 | OPS-080 | a downgrade that deletes rows in raw SQL is costed at zero | drops_in_downgrade reads only drop_column and drop_table, so a downgrade() whose body is op.execute('DELETE FROM ...') is costed at zero rows and assert_rollback_is_lossless prints 'nothing in those downgrade() bodies drops a table or a column, so no row is destroyed by undoing them' before destroying them. OPS-078 inverted the upgrade direction to an allowlist; the rollback direction still reads two verbs. | S |
| P13 | OPS-082 | every gate runs saas from an interpreter no founder has | cli/gates/scaffold.py:197 and cli/examples.py:278 both invoke the CLI as [sys.executable, '-m', 'cli.main'] out of .venv-verify, which carries the whole product stack. README.md tells a founder to uv tool install --editable, whose venv carries the CLI's five declared dependencies and nothing else. So every end-to-end gate exercises saas in an environment no user has, and OPS-077 - saas new writing no migration for anybody who followed the README - was green under all of them for its whole life. | M |
| P13 | OPS-120 | walk.py's three shapes no longer describe what saas new produces, so fifteen and nine are both wrong | make walk-benchmark is red on main and nothing in the gate ledger says so. saas new installs invite by default, whose dependency closure is auth, authz and webauth, so the core-only shape is not core-only and the core+auth shape's saas add auth changes nothing. Two necessity probes are firing correctly and the step count they guard has to come down, which makes docs/DEV-CHECKLIST.md's fifteen and nine both wrong and section A step 6's "core is already in" wrong with them. | M |
| P13 | OPS-137 | A shared resource with no declared separation is refused, not noted | adr-013 allows a product to share tier-two infrastructure only if the separation carries its own command, its measured cost and what is unavailable while it runs. Without a registry declaring those, the tier is prose and no gate can read it - the same reason personal_data.py, egress.py and SHELL_CONTEXT are declarations beside the code rather than documents describing the code. | M |
| P13 | OPS-138 | A scaffolded product must reference none of the factory's infrastructure | adr-013 says standalone has to mean something checkable rather than a claim in a README. A product tree containing an account id, an org-level resource name, a runner group or a bucket it does not own is coupled to the factory whatever the documentation says. This is the property that makes the whole decision enforceable, and it is decidable by reading a scaffolded tree. | M |
| P13 | OPS-150 | How a score gets revised after the world changes, and which signals can be recomputed rather than re-asserted | value and urgency are self-reported once at write time and never revisited, so when Actions stopped starting jobs on 2026-09-14 the correct response was to promote everything CI-dependent and nothing could - this ticket is the options and their costs, not the mechanism. | L |
| P13 | OPS-170 | every credential this project holds has a row naming its scope its holder and when it dies | OPS-169 read the whole security pile and found six tickets that are each one credential discovered by a person noticing - a Cloudflare DNS-edit token with no remaining job, a rotation procedure naming a variable no code reads, a token nothing revokes, a sign-in token committed to history, and encryption at rest configured nowhere. docs/SECRETS.md describes storage per deployment level and there is no register with one row per credential, so scope, holder, lifetime and blast radius are rediscovered every time. | M |
| P13 | OPS-171 | security impact is self reported and nothing corroborates it so a mis-tagged critical defect is invisible | OPS-169 swept every not-closed ticket whose security_impact was unset, none, low or medium and found seventeen describing a defect whose mechanism the security plan names as a cause - fourteen of them belonged at high. The tag is the only route into the security pile, it is written once by the ticket's author, and nothing checks it, so the pile was understating itself by 44 percent and a genuinely critical item could sit outside it indefinitely. | S |
| P13 | OPS-176 | nothing says what a product costs per tier and per component, minimum and maximum | Cost is currently a property of the deployment nobody looked at. Making it a property of a declared choice is what lets a founder pick a tier knowingly. | M |
| P13 | OPS-177 | spend is unbounded by construction and the two kinds of unbounded need different mechanisms | Two different failure shapes were being called by one name, and a spend limit only addresses one of them. | L |
| P13 | OPS-180 | this repo publishes no machine or spend inventory that a central ledger could consume | The owner ruled that home is the source of truth and each project feeds it. This repo currently publishes nothing machine-readable, so home would have to discover, which is the shape that produces a partial inventory looking complete. | M |
| P13 | OPS-190 | every agent pays for the whole CLAUDE.md, and most of it does not apply to it | The directory mechanism already exists and carries five times the root's words, so the question is not whether to scope but on which axis. Scoping by agent kind is right for exactly one thing and wrong for the rest. | M |
| P13 | OPS-202 | four exit criteria name the default postgres port, so running one writes into whichever agent's container is listening | Four done_when entries connect to a database at a hardcoded host and port they do not create, three of them the default 55432, while nine other criteria stand up their own container on a private port and tear it down. Running one of the four writes into whatever is listening, and the sweep did exactly that to another agent's container before noticing. | S |
| P13 | OPS-229 | no gate checks a ticket's path claims, so a stale citation reads as evidence | no reason written | S |
| P13 | OPS-264 | twelve tickets filed by OPS-255 and COMP-137 are scored with no priority, and score.py --check goes red on each | The engineering-manager lens is required on backlog/** and it is the only lens PRs 177 and 181 require, so twelve BAD lines from score.py --check are the whole reason neither research unit can be approved. | S |
| P13 | OPS-276 | The product-readiness and devops lens runs cannot pass on any tree, so no skeleton or cli ticket can reach reviewed | The two lenses review-policy.toml requires on skeleton/ and cli/ fail at dev's tip for reasons no diff can change, so stage 3 is unreachable for every ticket that touches them. | S |
| P13 | OPS-302 | Provision the chosen CI box and run the template's whole CI on it once, then walk the exit | OPS-299 proved runner.sh against a local stand-in with GitHub stubbed. Nothing has registered with GitHub, no cloud VM exists, the real runner tarball and --docker have never been exercised, and the workflows were written against GitHub's runner image rather than bare Ubuntu. The first real run is where the missing tools show up. | M |
| P13 | OPS-308 | an outside monitor account watches each production /healthz, and its URL is declared in saas.toml | OPS-307 built everything a product can do about a dead box without an account, and the check itself lives at an uptime service; until one exists for each live product, nothing notices that product's machine go away. | S |
| P13 | OPS-309 | make invite-walk is red on dev at founder-sends, and six claims fall behind it | contracts/invite.md criteria 2 and 4 to 7 are confirmed only by make invite-walk, and on dev the walk's founder gets 404 from /invites, so every claim after it fails and the contract's evidence is currently not reproducible. | S |
| P13 | OPS-312 | The owner delegates security decisions to the security lane, which decides and reports rather than asking | The owner, 2026-09-29: \"If there's something that you feel like you know what's the right decision, you can take it. Because you're the security expert. And I don't really care about security stuff. And if you can check the Hetzner, the Hetzner instances, then feel free. I'd rather not do it myself. And just try to do stuff that don't require decisions from me.\" | S |
| P13 | OPS-338 | propose_edges counts untracked files, so a regen in a dirty worktree commits the wrong EDGES.md and its own --check agrees | A generator whose output depends on untracked files is not a function of the commit. On #350 an agent worktree committed a docs/EDGES.md that a clean checkout of the same head rewrote by 40 lines, and propose_edges.py --write --check passed in the worktree that wrote it. techlead held the PR on it twice. | M |
| P13 | OPS-346 | the scaffold gate has no lock, so a done_when takes it without anyone knowing | The one-at-a-time rule for the scaffold gate is enforced by sessions messaging each other, and 11 criteria across 10 tickets run test_kit_gates or test_scaffold_e2e directly. A criteria sweep therefore takes the gate while nobody believes anybody is holding it, and neither party is doing anything wrong when it collides. Two sessions hand-passed the gate across 2026-09-29 and 30 on exactly that assumption. | M |
| P13 | OPS-347 | check_criterion_proof counts a criterion that could not load its own code as defect-present | AUTH-010's recorded proof for done_when entry 1 passes --verify on a FileNotFoundError, so an auth ticket's criterion is counted as able to fail when all that failed was loading a file that did not exist yet. | S |
| P13 | OPS-348 | check_criterion_proof reads exit codes as pytest, so a checker's 1 and 2 are backwards | scripts/exitcodes.py says 1 is INVALID, could not answer, and 2 is DRIFT, a finding. check_criterion_proof treats 2 as a usage error and counts every other non-zero, 1 included, as evidence the defect was present. For a repo checker that is backwards in both directions, and OPS-235's three proofs currently PASS on ModuleNotFoundError: No module named pydantic. | M |
| P13 | OPS-356 | prove_migration truncates the scaffold's .env, so the app cannot boot and no migration runs | The proof wrote APP_PORT and DB_PORT over the scaffold's .env with a truncating redirect, destroying the AUTH_JWT_SECRET that saas new generates. The app container exited 1 before any migration ran, so both CI race steps failed in 56 seconds. The redirect predates OPS-119 by a fortnight and was harmless until it, and CI stopped running a week after OPS-119, so nothing executed this proof in between. | S |
| P13 | OPS-357 | Fast gates is cancelled at 15 minutes because one step runs 884 criteria since main | The Tickets step took 840 of the job's 900 seconds and was cancelled mid-flight, so it never reported. Measured locally it needs 38m31s. The next largest step in the same job was 19s, so this is one pathological step rather than accumulated growth, and a cancelled job reports failure at the run level indistinguishably from a red gate. | S |
| P13 | OPS-374 | the marketing and business role, defined by the session that holds it | Nobody owned getting people to use what the template builds, and the owner asked the session that will hold that job to define it first. | S |
| P13 | OPS-381 | a drifted mutation site is found only by running the slow gate | OPS-184's fourth acceptance bullet asks that a site which drifts again is caught by something cheaper than a person running the gate, and nothing does that. OPS-379 is the proof - four sites drifted and stayed unmeasured until somebody ran a six-minute target that verify lists as unrun. | S |
| P13 | PROD-003 | Shared phone book | The smallest product that needs group-scoped authorization, so it forces the thing AUTH-008 describes and scratchpad could not reach. | L |
| P13 | PROD-005 | Nobody can be removed from a shared phone book, so the half of the invariant about losing a role has no caller | PROD-003 grants roles and never takes one away, so a demoted admin and a removed member are both unreachable through the API and the three attacks about them cannot be written. | M |
| P13 | PROD-007 | File drop, the smallest product whose erasure has to delete bytes | components/files has no caller in any example. The interesting half is not the upload, it is that erase_subject must reach object storage and not only rows, which is declared as the indirect disposition and proven only at template level. | L |
| P13 | PROD-009 | TimeMachine, the session lifecycle a stopwatch does not have | Start, pause, resume, stop and abort are the whole product, and abort is the one a stopwatch has never had. Every route here derives the session from the caller and takes no id, which is PROD-002's argument applied to a row that is identified by being open rather than by being owned. | M |
| P13 | PROD-011 | TimeMachine, one open session across devices that were offline | This is the rung. A timer runs while a phone is in a tunnel, and two devices can both believe a session is open without anybody doing anything wrong, so PROD-006's invariant is violated by physics rather than by an attacker. No product on the ladder has had a uniqueness constraint that a network partition can break, and adr-004 has never had a caller that needed one. | L |
| P13 | PROD-023 | The shop's address is still one string, and the fields it should be exist now | COMP-059 built the fields and declared them. Until the shop moves onto them, the only product that has the problem still has it. | M |
| P13 | PROD-071 | the interview asks where the money comes from before it asks anything about design | The recorded failure in this repository is exactly a payer-and-audience split failure, so this ordering is not a preference: it is the fix for the worst thing this project has shipped. | M |
| P13 | PROD-073 | a lens is a seat a user occupies, and an empty seat is a finding | It converts the interview from one conversation into a set of owned decision areas, and it makes an unowned area stateable instead of silently defaulted. The authz component already exists, so this is that component applied to decisions rather than to data. | L |
| P13 | PROD-074 | each lens needs a roster of personas, and an advisory seat that can object but not decide | The advisory seat is the mechanism that makes a radical useful without making him responsible, and the obligation to answer an objection is what separates it from consultation theatre. | L |
| P13 | PROD-075 | a decision has no record of who was consulted, what was rejected, and who decided | It is the same traceability the owner asked for on tickets, applied to decisions, and the decision is the unit that is currently missing everywhere: artifacts point at no reason and reasons point at no author. | L |
| P13 | PROD-076 | designers have no infrastructure, so there is nowhere for design work to land | Design output that is a picture needs translating, and design output that is tokens and components does not. Deciding which we produce decides whether PROD-077 exists at all. | L |
| P13 | PROD-078 | a question to the founder does not say what decision it affects | It is the only mechanism that keeps the interview short. A question that cannot name the decision it affects is a question that should not be asked. | S |
| P13 | PROD-079 | a product has no loops, and regeneration stops being possible at the first real user | The three loops have different costs and only one of them has the regeneration problem, which is the thing the owner is worried about. Separating them removes most of the worry. | L |
| P13 | PROD-082 | layer the token model the way components are layered, and decide whether it speaks DTCG | He proposed the design model mirror the component model - template plus optional components - and asked for outside evidence before we invent our own decomposition. The evidence says he is right, names the tier his analogy corresponds to, and turns up an interchange format stable since 2025-10-28 and backed by 40 organisations that already expresses everything PROD-081 asks for. | L |
| P13 | PROD-089 | the template is itself a SaaS with a site and paying customers, which contradicts the thesis | no reason written | XL |
| P13 | PROD-091 | a tier is derived from the interview and priced, not chosen from a menu | The free-or-paid line is a line through the component set, so the degraded variant is a second dependency closure over the same answers rather than a different product. That makes it buildable on machinery that now exists, and it makes the closure load-bearing for revenue. | XL |
| P13 | PROD-092 | the owner previews a change before publishing it, so the live thing and the drafted thing can differ | The hard part is not rendering a preview, it is that publish implies a state the live product does not have. Something must hold unpublished changes, which is a draft/published split rather than a render command, and designing it as a button is how that gets missed. | XL |
| P13 | PROD-097 | the questions asked by hand while scoping a real product are the interview the bank is missing | The eight-question bank missed almost everything a real product needed. Each question answered by hand in chat is evidence of what the interview should ask, and it is lost unless recorded. | M |
| P13 | PROD-104 | the interview asks how the product sends email, with a recommendation, and saas new installs it | ADAPTER_EMAIL is console by default and console is refused in production, so every product that sends mail meets a refusal at deploy that the interview could have settled with a reason. | S |
| P13 | PROD-108 | the interview asks whether the product charges yet and what beta users keep, and saas new writes BILLING_MODE and WEB_BETA_PROMISE | adr-007 makes BILLING_MODE and WEB_BETA_PROMISE decisions with no default, so a fresh product refuses without them (OPS-279, OPS-297), and the one moment the founder is being asked questions is the interview. | S |
| P13 | PROD-120 | the interview has no business seat: nothing asks who it is for, who it is not for, the competition or the market | The owner's second layer is the 10% that differs between products, and he named audience and competition as part of it. The interview asks neither. | M |
| P13 | PROD-121 | the reference set records what 45 paying SaaS ship and not how they got their customers | The template is being built to the features of 45 paying products, and nothing records how any of them found the people who pay. | M |
| P13 | PROD-124 | the seat spec format: what a complete answer looks like, in one shape every role reuses | The owner's interview judges completeness against a per-role spec of required outputs, and no such spec has a shape yet. Every other ticket in this flow needs the format first. | M |
| P13 | PROD-125 | the technical seat has no role file, and the owner reserved its name | The owner said a technical role belongs in the list and left open whether it is tech lead or architect. saas-techlead is named four times across roles/ and docs/ and has no role file, so a technical seat has no spec, no toolkit and no owner. | S |
From docs/state.json -> backlog.tickets, restricted to backlog.frontier. Priority is the derivation value + urgency, never the written field - python3.12 scripts/score.py --table is the rule.
Behind the scenes
How the project runs: the spending budget, the agents, the method and the dependency graph. Nothing here needs you.
Budget
The weekly figure with how far off an even pace it is, and the session figure beside it.
38%(6 points over pace)weekly, all models
13%this session
- even pace by now
- 32%
- resets
- Tue 13 Oct 04:00
- this half
- daytime, ends 20:00
- it may spend
- 6.2 points
As of 2026-10-08T06:21Z. This is the one figure on the page that is a function of the clock rather than of the tree, so it is stamped and is deliberately not drift-checked - it goes stale rather than going red.
python3.12 scripts/gen_budget.py --write reads the quota through scripts/budget.py, which shells out to claude -p /usage, and stamps it into docs/budget.json. This page renders that file as an ordinary tracked input, so the published build carries the figures and gen_dashboard.py --check still covers every byte of it. docs/REVIEW-SWEEP.md is the precedent.
Cost
Where the weekly quota went. 1 credit is 1% of the week.
Cost this week: 38% · top: saas-main 11%. Attributed to a line: 38.8 credits.
By role, this week
| role | credits | of which subagents |
|---|---|---|
| saas-main | 10.8 | 6.3 |
| saas-fullstack | 6.6 | 0.0 |
| saas-devops | 5.7 | 0.0 |
| saas-security | 5.5 | 1.2 |
| saas-docs | 4.6 | 0.0 |
| saas-product | 2.2 | 0.0 |
| the rest | 3.3 |
By day
| day | credits | |
|---|---|---|
| 2026-10-02 | 0.0 | |
| 2026-10-03 | 0.0 | |
| 2026-10-04 | 0.0 | |
| 2026-10-05 | 0.0 | |
| 2026-10-06 | 15.8 | |
| 2026-10-07 | 19.3 | |
| 2026-10-08 | 3.8 |
By ticket, last five weeks
| ticket | credits | PR |
|---|---|---|
| OPS-174 | 2.7 | #481 |
| COMP-130 | 2.0 | #146, #148, #167 |
| OPS-220 | 2.0 | |
| CORE-082 | 1.3 | #58 |
| CORE-100 | 1.1 | #143, #144 |
| OPS-206 | 1.1 | #26 |
Hosting, per month
| service | cost | basis |
|---|---|---|
| Fly.io | USD 2.32 | measured 2026-09-17, toy shop idle |
| Cloudflare | USD 0 | free plan, DNS and Pages |
| Resend | USD 0 | free tier, no card |
| Backblaze / object storage | USD 0 | not set up yet |
| Hetzner | not ours | billed outside this repo |
| GitHub Pro | unknown | OPS-175 owns finding out |
As of 2026-10-08T06:21Z. Fitted to 449 quota readings over 3 week(s): error 3.4 points across all readings, worst 12 at a week's end, weekly rate up to 17% off the pooled one. Usage off this laptop is spread across the lines.
python3.12 scripts/cost_report.py --write sums the token counts in the session transcripts and calibrates them against the quota readings. No message text is read into it. docs/COST.md says how far to trust each line.
Agents
Whether an agent is running right now is not knowable from this tree, and this page does not guess. A worktree outlives the agent that made it - the root CLAUDE.md records four left behind by one laptop sleep, one of them holding main - so counting worktrees counts abandonment, not activity. DISPATCH.md is the register of what is in flight and it is maintained by hand.
- agents running
- unknown
- tickets marked in progress
- 33
| Ticket | Title | Branch |
|---|---|---|
| CLI-051 | the examples gate declares BILLING_MODE and not WEB_BETA_PROMISE, so every page test in paid-notes 500s | atomic/cli-051/examples-gate-web-beta-promise |
| COMP-133 | Social performance analytics: official-API insights per post and audience, stored and shown to the operator | atomic/comp-133/social-analytics-core |
| COMP-136 | the signed-in app shell: nav, layout, settings pages and a component kit every product rebuilds | atomic/comp-136/app-shell |
| COMP-163 | a site password gates every path of a server-rendered product, before accounts | no branch named |
| COMP-233 | a feature built API-first is invisible on its own page, because the routes take a bearer token and the page holds a cookie | atomic/comp-233/cookie-session-path |
| CORE-067 | The personal-data gate is table-level, so a new column on a declared table walks past it | atomic/core-067/column-coverage |
| DOC-057 | DEV-CHECKLIST section A does not run as written | no branch named |
| OPS-038 | The repository's own protection settings are clicks, and the OpenTofu that would replace them cannot be applied on the current GitHub plan | no branch named |
| OPS-056 | The negative control proving the migration lock is load-bearing did not break in CI, so the lock is unproven there | atomic/invisible-tests/race-control |
| OPS-136 | An org-level CI runner that every product can leave | atomic/ops-136/ci-on-our-own-box |
| OPS-218 | settings-audit checks a field is read, not that an operator can discover it | no branch named |
| OPS-279 | a fresh scaffold's make imports is red on BILLING_MODE and the kit gates cannot see it | atomic/ops-279/scrubbed-gate-env |
| OPS-309 | make invite-walk is red on dev at founder-sends, and six claims fall behind it | no branch named |
| OPS-310 | The owner asked the security lane to fix the high-importance security tickets | no branch named |
| OPS-319 | check_product_ci --self-test prints FAIL lines that read as real findings | atomic/ops-319/self-test-output-shape |
| OPS-328 | check_done_when has 73 findings on dev and they are eight causes, so make tickets stays red | atomic/ops-328/quoted-word |
| OPS-346 | the scaffold gate has no lock, so a done_when takes it without anyone knowing | atomic/ops-346/gate-lock-build |
| OPS-347 | check_criterion_proof counts a criterion that could not load its own code as defect-present | atomic/ops-347/load-error-frames |
| OPS-348 | check_criterion_proof reads exit codes as pytest, so a checker's 1 and 2 are backwards | atomic/ops-348/exit-codes-build |
| OPS-349 | prove_restore.sh dies at hetzner.sh backup, because the erasure-ledger export runs the app under ENVIRONMENT=production with the console mailer | atomic/ops-349/probe-mail |
| OPS-354 | the five walk gates still drive saas from the verify venv | no branch named |
| OPS-355 | admin_surface_walk nests three TestClient lifespans on one app, so error_sink.stop raises | atomic/ops-355/probe-one-lifespan |
| OPS-356 | prove_migration truncates the scaffold's .env, so the app cannot boot and no migration runs | atomic/ops-356/probe-env-clobber |
| OPS-357 | Fast gates is cancelled at 15 minutes because one step runs 884 criteria since main | atomic/ops-357/split-tickets |
| OPS-358 | a ticket reservation commits straight to dev and leaves the generated state stale until the next regen | atomic/ops-174/generators-ignore-stubs |
| OPS-365 | every product inherits workflows that hardcode ubuntu-latest, so no product can move CI to the box | atomic/ops-365/product-runner-switch |
| OPS-366 | mypy 2.4.0 types reversed() as Any, so typecheck is red on both faces | atomic/ops-366/reversed-is-typed |
| OPS-367 | the whole verify toolchain floats, so a stale venv reads green while CI and every product read red | atomic/ops-367/one-pinned-verify-toolchain |
| OPS-368 | the cloud-init gate needs tofu and CI has none, so it passes on a laptop and fails in CI | atomic/ops-368/one-pinned-gate-tool-pattern |
| OPS-374 | the marketing and business role, defined by the session that holds it | atomic/roles/marketing-v2 |
| OPS-377 | the security lane checks in on a round-hour schedule and decides on purpose whether to work or rest | no branch named |
| PROD-122 | the platform has no reach-and-convert layer: a product built on it cannot run ads, measure what they bring, or turn a visitor into a payer | atomic/marketing/reach-layer |
| PROD-123 | the product flow has no written design: frozen template, interview by role seats, one planning step, then the fleet | no branch named |
The worktree census is deliberately not published. It is read from the machine the generator ran on, so it is not a fact about this repository, and its rows are absolute checkout paths and other agents' branch names. Neither belongs on a public hostname.
In-progress tickets from docs/state.json -> backlog.tickets, where status is in_progress. Liveness is from nowhere, because nothing in the tree records it - DISPATCH.md is the hand-written register and docs/QUEUE.md is what gets an agent next.
How this project works
The machine rather than its output. Every document below is rendered here in full, so reading it does not mean cloning a repository. The prose is set in a serif and the dashboard is not, which is the only signal you need for which half of this site you are in.
PURPOSE.md
What this is for, and the finish line
docs/PURPOSE.mdGLOSSARY.md
Terms this project uses in a specific way
docs/GLOSSARY.mdMETHOD.md
Which document owns what, and what it does not
docs/METHOD.mdPROCESS.md
The rules. Each one names its enforcer
docs/PROCESS.mdPLANNING.md
How the next unit gets chosen
docs/PLANNING.mdREVIEW-SWEEP.md
Which tickets the sweep is asking about
docs/REVIEW-SWEEP.mdDELEGATION.md
What an owner decides without asking
docs/DELEGATION.mdAI-LED-DEVELOPMENT.md
Failure modes of the arrangement itself
docs/AI-LED-DEVELOPMENT.md19 terms defined, and the first 48 of them
Terms this repository coined or bent. A word owned by an RFC or a vendor lives in docs/BORROWED-TERMS.md instead, because a glossary that restates a standard is wrong the day the standard moves and wrong in a way nobody notices.
A term that already means something elseP0, P1, P2, P3tokens per unitturns per unitThe kitThe pipelineSlots, and the surfaces that have themThe one invariantThe industry's specification documentsThe product lifecycleA ticket's end, and its last reviewMeasurementSpending the quotaUnder loadFailure directionsShapes of defectCapability URLConventions inherited from elsewhereWords used loosely, and what they meant
Rendered from docs/PURPOSE.md, docs/GLOSSARY.md, docs/METHOD.md, docs/PROCESS.md, docs/PLANNING.md, docs/DELEGATION.md and docs/AI-LED-DEVELOPMENT.md at generate time.
The dependency graph
189 edges over 455 dispatchable tickets, and only 46 of those edges still hold anything back. The graph is almost empty, which is why nothing can say what to work on next: 348 unbuilt tickets have no edge at all, and the 68 fragments that do are not one graph.
- edges
- 189
- still blocking
- 46of those
- fragments
- 68
- largest fragment
- 32nodes
- no edge at all
- 348
From docs/state.json -> backlog.graph, undirected for components. An edge whose upstream ticket is already built is counted as an edge and not as a blocker, which is why edges and still blocking disagree by 143.