21 slides · use ← → · built from the report
existing-system audit
Two years of good engineering and not a single launch. The system can quietly block the shop floor and has no way to say so — which is why the owner of two working factories keeps stepping back.
PL1 · direction · proposed
This is the cheapest policy in the set, and it targets the most expensive defect. Everything breaks in one place: the channel that serves as the task board has no state.
PL2 · direction · proposed
The project has 6,114 rspec examples and 95.71% line coverage. The BE developer runs them regularly , so the suite is not dead: it covers the changes that pass through his hands.
A startup grant of up to USD 100k requires a launched version of the product, preferably with revenue. The thread lived for a week in December 2025 and died after a meeting was rescheduled. Over the following seven months the word “grant” does not appear in the export once.
In May 2025 the developer designed a “fallback function so the admin could manually enter data about completed processes”. In June 2026 it got full CRUD for shift processes on the web and seven e2e specs. The mobile half of the loop, the half that carries the promise, has not been tested on people since August 2025.
| Owner | domain truth, priorities, money, access to two factories | technical strategy — no expertise |
| BE developer | backend domain, Heroku infrastructure | does not take on improving the machine or engineering leadership |
| FE developer | CI, ADRs, PRDs, harness, e2e, and in practice the backend too | no deep BE expertise; on 2026-07-30 asks whether he should look for a job |
A quantity reservation with no expiry stops the next person on the operation. Observability is zero. For a factory, time to detection equals downtime, and the detection mechanism today is the owner writing in Telegram.
| Rule | Written where? | Health | |
|---|---|---|---|
| S1 | Quality is ensured locally and voluntarily, not by gates. Evidence : 6,114 examples, 95.71% coverage, and not a single job that runs them. | not written down anywhere | the suite is excellent, protects no one |
| S2 | A known test failure is the normal state. Evidence : seven rspec failures are known to the developers, documented and tolerated to this day. | shadow — held by the machine, not a document | works as a norm and destroys the signal |
| S3 | The task board is Telegram. Evidence : 5,735 messages, no tracker; the launch date, the grant and the measured complaint all dissolved the same way. | not written down anywhere | no — the channel has no state |
| S4 | Architectural discipline is set by the frontend. Evidence : FSD boundaries as CI errors, two ADRs, a 426-line harness, pinned skills. | ratified in frontend_v2/CLAUDE.md and the CI gates | yes — the project's best-working strategy |
| S5 | Backend context lives in the private memory of the developer's agent. Evidence : there is no root CLAUDE.md or AGENTS.md; across the whole repository there are two harness artifacts, both frontend. | not written down anywhere | no — knowledge does not accumulate |
| S6 | When adoption stalls, we rewrite. Evidence : v1→v2 since February 2026, a wave of 70/44/35 commits a month, a rework of the materials model in July 2026. Since September 2026 the mobile app is being rewritten, and there has still never been a launch at a factory . | not written down anywhere, but prescriptive in practice | produces quality, does not produce a launch |
| S7 | No one holds the product promise. Evidence : the loop failed in August 2025 and has not been tested since, the fallback path grew up alongside it, and there is no written trace of a decision about this . | by default — through the absence of a decision | no |
Getting into the system costs more than getting out of it; failure is silent and dangerous at the same time; the owner's complaint has nowhere to go; a known defect costs nothing to ignore; the promise is neither tested nor withdrawn; no one is responsible for the engineering machine and the sequencing of work. Rewriting code cures none of the six; all six are cured by decisions about where the signal goes and who reads it.
| Risk | Flag | Likelihood | Would you notice? | |
|---|---|---|---|---|
| R1 | The line stops, and nobody finds out | high in the first week of real work: both scenarios already happened in 2025 | close to zero: there is no error tracking, Heroku logs sit in a ~1,500-line buffer with no search, and the only reliable signal channel is the owner writing in Telegram | |
| R2 | The sole knowledge holder, also the only leadership candidate, leaves | reduced but not removed: the project is full-time work for the FE developer, and the 2026-07-30 question about looking for a job came from a lack of tasks; since September 2026 he has been rewriting the mobile app. The workload came from a new rework, not from an agreement, so the risk returns once the rework is finished | high: it has already been said out loud, a rare case of a loud risk | |
| R3 | The scan loop still does not work, and this surfaces only after onboarding | unknown, and dangerous for that reason: the audit has no access to the mobile app repository | zero until the first day on the shop floor | |
| R4 | The money runs out before launch | medium: the amounts fluctuate, there is a five-month gap in payments, and an amount is outstanding | medium: the receipts are visible, but the real accounting is kept in a spreadsheet the audit cannot access | |
| R5 | The owner stalls on data entry again | materialized: as of 2026-09-08 there is still no factory launch; the owner stalled on how to group the equipment, and there is still no loading mechanism either | high: it shows as days of silence in the channel | |
| R6 | The mobile app contains defects unknown to the audit | unknown | low |
| Debt | Kind | |
|---|---|---|
| D1 | rspec outside CI | organizational and technical |
| D3 | Zero observability | technical |
| D4 | Two client surfaces for two pairs of hands | strategic |
| D8 | Zero security gates and zero dependency hygiene | technical |
| D5 | Backend context exists only in an agent's private memory | knowledge |
| D6 | Telegram serves as the task board | organizational |
| D7 | A quantity reservation with no expiry | technical |
| Credit | Status | |
|---|---|---|
| C1 | The backend test suite: 6,114 examples, 95.71% of lines, 82.12% of branches | works, but covers only half of the changes |
| C2 | 303 e2e tests in 110 files, with fixture infrastructure | confirmed — the suite passes in full |
| C3 | e2e fixtures as a reference set for agentic onboarding | confirmed — the most valuable credit for B3 |
| C4 | The system already produces a product's full tech card | confirmed — this is the system's output, not its input |
| C8 | e2e gives 79% backend coverage and 81% frontend coverage | confirmed |
| C5 | Documentation: PRD, user stories, data models, two ADRs | confirmed |
| C6 | The frontend's agent harness | confirmed |
| C7 | The owner as a domain oracle | confirmed |
| Win | Feeds | Day | Status | |
|---|---|---|---|---|
| E2 | An rspec job in the existing workflow, plus quarantine of the seven known failures with an issue. Executes PL2. | verification: tests in the pipeline | 0.5 | — |
| E3 | Record coverage from both suites, not just rspec: SimpleCov in the :test group gives 95.71% from unit tests and 79.05% from e2e (the same SimpleCov in the Puma process), and vite-plugin-istanbul plus nyc give 80.72% of the frontend. A CI artifact and Codecov make C1 and C8 visible to the team for the first time; today nobody has seen any of these numbers. | verification: coverage floor | 0.5 | — |
| E4 | Sentry in the backend and in both frontends. Source maps are already uploaded; only the receiver is missing. Set it up with the Sentry → GitHub Issues integration from the start, because that is what makes PL1 complete: the machine signal lands in the same tracker as the human one. Closes half of D3. | observability: error tracking | 0.5 | — |
| E5 | Connect a log drain on Heroku. The logs currently live in Logplex: a buffer of ~1,500 lines kept for at most a week, with no search . A drain forwards every line to an external service that stores it and makes it searchable, so investigating a failure on the shop floor stops meaning “reproduce it again.” | observability: structured logs | 0.2 | — |
| E6 | A separate database for rspec in the test stack. It removes the deadlock that keeps the suite from starting normally. | verification: fast feedback | 0.2 | — |
| E7 | A top margin on the QR label. The developer named this as the cause of poor scanning in August 2025. | release safety: print quality | 0.1 | — |
| E8 | A root AGENTS.md for the backend modeled on frontend_v2/CLAUDE.md: rules, commands, pitfalls, a domain map. Closes D5. | agent harness: context routing | 1.0 | — |
| E10 | brakeman and bundler-audit as gems, plus two jobs in the existing workflow. Closes half of D8. | static gates: security scanners | 0.3 | — |
| E11 | .github/dependabot.yml for two ecosystems (bundler and npm). The second half of D8. | dependency hygiene: automatic updates | 0.2 | — |
| E9 | A script to dump and restore the production database, with verification. It is a prerequisite for any pilot on real data. | release safety: verified backups | 0.5 | — |
| Bet | Verdict | Addresses | Cost | |
|---|---|---|---|---|
| B1 | Make failure visible and safe: error tracking, a timeout on the reservation of an unfinished process, idempotent process creation, an alert on a blocked operation. R1 · RC6 · D3 · D7 | Do | ≈1 week | |
| B2 | One product, one workshop, in parallel with the existing books. Load the product from whatever source the owner actually has (Q6), by hand or with an agent. The readiness criterion already exists: the system must produce a tech card that matches the paper one C4. Then run the full cycle through to a closed shift and calculated pay, reconciling against the existing books every day. RC4 · RC5 · R3 · R5 | Do | ≈6 weeks, 2 of them on the shop floor | |
| B4 | Appoint an owner of the engineering machine: one person responsible for CI, deploys, observability and the sequencing of work, with the access that makes this possible. There is one candidate. RC2 · R2 · D5 | Do | one conversation + access | |
| B3 | Agentic onboarding as a repeatable mechanism: a skill that reads the owner's source data (in whatever format Q6 establishes) and fills a factory through the API, idempotently and with a dry run. It learns from the e2e fixtures as a reference set C3 and is checked against them. RC5 · C3 | Wait for B2 | ≈2 weeks after | |
| B5 | The mobile app: either audit it with the same discipline, or officially recognize web mode as primary and withdraw the promise. R6 · RC4 | Decide | ≈3 days for the audit | |
| B7 | A one-off QA consultation on the existing e2e suite: is the methodology right, and which critical paths are missing? Not a hire, but an outside look at what is already written. C2 · R3 · RC4 | Buy once | a few hours of consulting | |
| B6 | The v1→v2 migration was completed without this report: the v1 build was removed from the pipeline on 2026-07-10, and the directory itself was added to .slugignore on 2026-07-22. | Done | D4 | — |
Shveika 8 claims more than 550 Ukrainian enterprises, ships barcoding of technological operations in the ready-made solution, and sells a productized paid onboarding, “Prymirka” (2 months, UAH 11,000, credited toward the purchase). The mobile loop on the shop floor is not a SaaS ERP differentiator but an expected feature, shipped by the competitor and unconfirmed here.
The list of banned software from 9 January 2026 applies to the state sector and critical infrastructure; bill No. 13505 with fines has not been adopted. Meanwhile BAF was designed as an approximation of 1C, so moving 1C → BAS is cheaper than moving 1C → SaaS ERP, and most of the migration wave flows there.
| 2026-09-13 | PL2: whether the gates are switched on and whether they have stopped even one merge | the technical owner (B4) |
| 2026-09-13 | Easy Wins E2–E11: what shipped, what overran its day and what resisted | the technical owner |
| 2026-10-13 | PL3 and PL5: whether the pilot started, whether the daily discrepancy is reconciled | the business owner |
| 2026-10-13 | PL4: which column the work actually went into | the business owner |
| 2026-11-13 | PL1: how many complaints became issues and how many of them were closed | the technical owner |
| 2026-11-13 | C1 and C2: whether they moved from projected to confirmed | the technical owner |
| 2027-02-13 | PL6: the mobile app rewrite began in September 2026; whether its reason, exit criterion and date are written down | the technical owner |
Before the conclusions
How much of what you just heard was actually observed.