Project Overview Documentation Index Drop Documentation Index Last updated: 2026-02-17 | Validated: 20/20 PASS after doc alignment audit Backend Document Description API Reference All 26 API endpoints — method, path, request/response, auth, rate limits Database Schema All 19 tables (12 core + 7 compliance) — columns, types, constraints, indexes Authentication JWT auth flow — register, login, refresh, logout, middleware Services External integrations — Sumsub (KYC) [PRODUCTION] , Stripe (Cards) [MOCK] , Swan [DEPRECATED] Currency Rates FX rate source, DB cache/freshness, rate limiting, supported NOK corridors, verification findings Middleware Auth, validation, rate limiting, CSRF, error handling Feature Flags 8 feature flags, 16 tracked features, server/client APIs Frontend Document Description Component Inventory All components — custom, icons, shadcn/ui primitives Pages All 20 routes — auth, components, data fetching, compliance pages Design System Colors, typography (Fraunces/DM Sans/Geist Mono), spacing, patterns State Management useAuth hook, feature flags, data fetching patterns Landing Pages Marketing site — 9 sections, 12 sub-pages, waitlist API Mobile Document Description Mobile App Expo Router architecture, 8 screens, API client, theme Role-Based UX + Demo User Matrix + BankID Mock Merchant-only Profile UX, seeded demo users, BankID demo-mode behavior — verified against source 2026-07-28 Infrastructure Document Description Deployment Docker, Fly.io, 3 deployment configs (MVP/Production/Staging) CI/CD GitHub Actions pipeline — lint, test, build, e2e, docker (5 jobs) Monitoring Health checks, container monitoring, gaps identified Environment Tech stack, npm scripts, Next.js config, env modes Security Document Description Security Architecture JWT, cookies, bcrypt, CSRF, rate limiting, input validation Compliance PSD2, AML, GDPR, DORA readiness — 8/100 overall, remediation plan PCI-DSS SAQ-A Readiness Applicability determination + SAQ-A gap list for the (currently disabled) Cards feature Testing Document Description Testing Guide Vitest + Playwright, running tests, mocking, patterns Test Inventory All 14 test files — unit, integration, e2e, regression, performance Quality Assurance Document Description Validation Report Cross-reference audit of all docs against source code Business Case (ZiCA v2) Drop — Business Case v2 (Remittance + QR Payments) Note: Originally titled "Drop — Business Case v2". Product has been rebranded to Drop . Target audience broadened from diaspora-only to ALL residents in Norway/Scandinavia. Business model updated to pass-through PSD2 (PISP/AISP) — Drop NEVER holds customer money. See Drop CLAUDE.md for current spec. Date: 2026-02-08 (updated 2026-02-14) Version: 2.1 Compiled by: John (AI Director) Sources: 8 AI agents — 2 runde analize Pivotni insight: Alem Executive Summary Drop je fintech app za sve stanovnike Norveške/Skandinavije sa dva revenue streama: Remittance — pošalji novac u inostranstvo jeftinije (primatelj NE treba app) QR Merchant Payments — plaćaj u dućanu skeniranjem QR koda (kao UPI u Indiji) Isti korisnik, dva use-case-a, pass-through PSD2 model (Drop NIKAD ne drži novac korisnika). Ovo stvara flywheel efekat. 1. Vizija ┌─────────────────────────────────────────────────────────┐ │ DROP ECOSYSTEM │ │ │ │ POŠILJALAC (Norveška) PRIMATELJ (inostranstvo)│ │ ┌──────────┐ ┌──────────┐ │ │ │ Drop App │─── remittance ──▶│ Bank/Cash │ │ │ │ (PISP) │ via Open Banking│ (no app!) │ │ │ └────┬─────┘ └──────────┘ │ │ │ │ │ │ QR scan │ │ ▼ │ │ ┌──────────┐ │ │ │ Merchant │ ← lokalni biznisi u Norveškoj │ │ │ QR Code │ ← jeftiniji od Vipps (1% vs 1.75-2.75%) │ │ └──────────┘ │ │ │ │ FLYWHEEL: │ │ Više korisnika → više merchanta → više korisnika │ │ DROP NIKAD NE DRŽI NOVAC — pass-through PSD2 model │ └─────────────────────────────────────────────────────────┘ 2. Tržište (data-engineer agent) Podatak Vrijednost Izvor Imigranti u Norveškoj ~1,000,000 SSB Remittance iz Norveške godišnje 5.7 mlrd NOK World Bank Prosječna remittance tx ~1,000 NOK World Bank SME u Norveškoj ~195,000 SSB Top remittance korridori Srbija, Poljska, Pakistan, Iran, Turska SSB Lokalni biznisi (procjena) 30,000-50,000 SSB estimate 3. Dva Revenue Streama Stream 1: Remittance Aspekt Detalj Šta Slanje novca iz Norveške u Balkan, Pakistan, Tursku, itd. Kako Drop app → PISP (Open Banking) via bank partner → bank transfer/cash pickup Primatelj NE treba app — prima na račun ili cash Fee 0.5% (vs Wise 0.7-1.5%, vs WU 5-10%) Corridors NOK→RSD, NOK→BAM, NOK→PKR, NOK→TRY, NOK→PLN, NOK→EUR Stream 2: QR Merchant Payments Aspekt Detalj Šta Plaćanje u dućanu skeniranjem QR koda Kako Merchant prikaže QR → customer skenira → instant transfer Merchant Lokalni biznisi (kebab, kiosk, pekara, restoran, frizer) Fee 1% (vs Vipps 1.75-2.75%) Settlement Daily batch payout na merchant bank račun Tech qrcode.js (generisanje) + html5-qrcode (skeniranje) Flywheel Korisnik šalje remittance → navikne na Drop → plaća u lokalnom dućanu QR-om Merchant prihvati QR → preporuči Drop → korisnik šalje i remittance → REPEAT 4. User Journeys Journey A: Remittance Amir otvori Drop, tap "Pošalji novac" Odabere: Srbija, mama Jasmina, njen broj računa Unese 2,000 NOK → vidi: primatelj dobije 23,400 RSD, fee 10 NOK (0.5%) Potvrdi, plati sa norveške kartice Mama dobije SMS: "Primili ste 23,400 RSD od Amira" Novac na računu za 1-2 radna dana Journey B: QR Payment Amir uđe u Ahmetov kebab shop u Oslu Na kasi je Drop QR naljepnica Amir otvori Drop, tap "Skeniraj" Skenira QR → prikaže se: "Ahmetov Kebab, unesi iznos" Unese 129 NOK, tap "Plati" Ahmet dobije notifikaciju: "Primljeno 129 NOK od Amir" Instant. Bez terminala. Fee 1.29 NOK umjesto 3.55 NOK (Vipps). Journey C: Killer Combo Amir šalje 5,000 NOK mami — dobije 25 Drop bodova Plaća kebab 129 NOK QR-om — dobije 1 bod Na 50 bodova: besplatna remittance (no fee) Ahmet (merchant) vidi: "Ove sedmice: 47 transakcija, 12,300 NOK, fee 123 NOK" Ahmet preporuči Drop svim korisnicima → novi korisnici → više remittance 5. Merchant Onboarding (3 minuta) Vlasnik skine Drop app Tap "Registruj biznis" → unese: naziv, adresa, bank račun KYC: lična karta + org.nummer Dobije QR kod — printaj ili koristi na telefonu Lijepi QR na kasu Gotovo. Prima plaćanja odmah. 6. Finansijski Model (KORIGIRAN — realistične projekcije) Startup Costs Stavka Iznos (NOK) Development (AI-first) 10,000 Open Banking integracija (PSD2) 15,000 Legal + compliance setup 50,000 Marketing launch 100,000 QR naljepnice + merchant kit 20,000 Buffer 55,000 UKUPNO 250,000 NOK Revenue Projection (KONZERVATIVAN) Period Remittance korisnici Merchant-i MRR Remittance MRR Merchant Ukupni MRR Mj 1-3 200 20 2,000 10,000 12,000 Mj 4-6 1,000 80 10,000 40,000 50,000 Mj 7-12 3,000 200 30,000 100,000 130,000 Year 1 avg 3,000 200 30,000 100,000 130,000 Year 2 avg 8,000 500 80,000 250,000 330,000 Year 3 avg 15,000 1,000 150,000 500,000 650,000 Napomena: MRR Remittance = korisnici × 2 tx/mj × 1,000 NOK × 0.5%. MRR Merchant = merchanti × 50,000 NOK/mj promet × 1%. ARR Projection Godina ARR (NOK) Year 1 ~1,000,000 Year 2 ~4,000,000 Year 3 ~7,800,000 Monthly Costs (post-launch) Stavka NOK/mj Bank partner fees 10,000-20,000 Hosting + infra 2,000 Claude Code (development) 1,100 Marketing (ongoing) 30,000-50,000 Support + compliance 10,000 Mjesečni burn ~55,000-85,000 Break-Even Scenarij Break-even MRR Kad? Optimistički 85,000 NOK/mj Mjesec 5-6 Realistički 85,000 NOK/mj Mjesec 7-9 Pesimistički 85,000 NOK/mj Mjesec 12-14 Unit Economics Segment CAC LTV (24mj) LTV:CAC Consumer (remittance) 100 NOK 2,400 NOK 24:1 Merchant (QR) 500 NOK 24,000 NOK 48:1 Merchant LTV je IZUZETAN jer je recurring i visok volumen. 7. Competitive Landscape Konkurent Remittance QR Payments Dijaspora focus Fee Vipps ❌ Samo Norveška ✅ Ali skupo za merchante ❌ 1.75-2.75% merchant Wise ✅ Cross-border ❌ No merchant ❌ 0.7-1.5% Revolut ✅ Ali generic ❌ Limited ❌ 0.5-1.5% Western Union ✅ Ali skupo ❌ ✅ Ali 2005 UX 5-10% MoneyGram ✅ Ali skupo ❌ ✅ Ali 2005 UX 4-8% Drop ✅ Jeftino ✅ QR (1%) ✅ Za sve u Norveškoj 0.5% + 1% Niko ne radi oba. To je naš moat. 8. Tech Architecture (dev agent) QR Payment Flow ┌──────────┐ scan ┌──────────┐ confirm ┌──────────┐ │ Merchant │────────────▶│ Customer │─────────────▶│ Drop │ │ QR Code │ camera │ App │ amount │ Server │ └──────────┘ └──────────┘ └─────┬────┘ │ PISP via Open Banking (direct bank transfer) │ daily batch settlement │ ┌─────▼────┐ │ Merchant │ │ Bank Acc │ └──────────┘ Key Tech Decisions Decision Choice Why QR generation qrcode.js Lightweight, static QR per merchant QR scanning html5-qrcode Camera API, works on all phones Payment initiation PISP (Open Banking) Direct from user's bank account Settlement Daily batch payout Via BaaS partner to merchant bank Offline Store-and-forward Queue payments locally, sync when online 9. Roadmap Version Timeline Features Revenue Impact v1 MVP 5 sedmica Remittance (3 corridors: RSD, BAM, PLN) + basic QR payment First revenue v2 +4 sedmice More corridors (PKR, TRY, EUR) + merchant dashboard + loyalty Growth v3 +6 sedmica Business accounts + invoice integration + API for partners Scale v4 +8 sedmica White-label za partnere + advanced analytics New revenue stream 10. Risk Matrix (Updated) Rizik Severity Mitigacija Bank partner dependency HIGH Multi-provider ready, modular architecture Vipps launches remittance HIGH Already ahead in market, community trust Regulatory issues MEDIUM Agentmodell under bank partner licence Slow merchant adoption MEDIUM Door-to-door u lokalnim zajednicama Security breach CRITICAL Threat model + security agent + httpOnly JWT Cash flow pre break-even MEDIUM Bootstrap + Innovasjon Norge grant 11. GO / NO-GO Za GO: Startup cost: 250K NOK (bootstrapable) Break-even: 7-9 mjeseci (realistično) LTV:CAC: 24:1 (consumer), 48:1 (merchant) Tržište: 5.7 mlrd NOK remittance + 30,000+ immigrant biznisa Niko ne radi remittance + QR combo u Norveškoj Alem razumije problem iz prvog lica — autentičnost Rizici: Marketing budget je realan trošak (~50K NOK/mj) Compliance je ongoing Alem je jedini human — decision bottleneck Preporuka: GO Ovo nije "još jedna payment app". Ovo je specifičan alat za sve u Norveškoj koji šalju novac u inostranstvo ili žele jeftinije plaćanje u lokalnim dućanima. Build MVP, launch u Oslu, grow from there. Agents koji su doprinijeli (v2) Agent Runda 1 Runda 2 Ukupan doprinos nicksaraev Biznis model Dual revenue + TAM Revenue strategy product Product strategy User journeys + roadmap Product vision legal Compliance — Regulatory map finance Budget Dual stream financials Financial model marketer GTM strategy — Marketing plan security Threat model — Security architecture dev Architecture QR tech architecture Tech decisions data-engineer — Market data Tržišna analiza 8 od 15 agenata aktivirano. 2 runde analize. Alemov insight: širi tržište, ne samo dijaspora. Compiled: 2026-02-08 by John (AI Director) Status: Awaiting Alem GO/NO-GO Bilko — Project Handbook Bilko — Balkan Accounting SaaS BookStack — Provjeri PRVO Prije traženja bilo čega — provjeri BookStack (https://docs.basicconsulting.no). Centralna baza znanja za tools, skills, hooks, agents, rules, projekte, klijente, dokumentaciju. Ako odgovor postoji tamo — NE TRAŽI dalje. Quick Info What: Cloud accounting for Balkan SMBs (Serbia, BiH, Croatia) Target: 50K-500K SMBs across Balkan region Inspiration: Fiken (Norway) — simple, compliant, affordable Pipeline: See PIPELINE.md (8-gate checklist) Project ID: bbd77cc0 Domains: bilko.io (primary), bilko.rs (Serbia), bilko.cloud (Croatia / HR), bilko.company (Bosnia / BA) Landing pages: apps/landing-hr/ (bilko.cloud) + apps/landing-ba/ (bilko.company) — deployed to CF Pages Branding Name: Bilko (from Serbian "bilans" = balance sheet) Primary Color: #8B6BBF (Plum) Secondary: #5B3E8A (Deep Plum) Accent: #F2C87A (Gold) Surface: #F9F7FC (Light Lavender) Text Dark: #231C33 Font Heading: National Park Font Body: Work Sans Font Mono: DM Mono Grid: 8px spacing system Icons: Lucide React Tech Stack (updated 2026-03-17) Frontend: Next.js 15 + React 19 + TypeScript + Tailwind CSS 4 + shadcn/ui (ALAI standard ✓) Backend: Kotlin/Ktor + Exposed + Flyway (ALAI standard, sole canonical backend, ADR-020+ADR-021). CEO removed Express/api-express 2026-05-02 (MC #10493). State: Zustand (installed but mostly React hooks currently) Charts: Recharts (BarChart, PieChart, LineChart) Monorepo: Turborepo Project Structure Bilko/ ├── apps/ │ ├── web/ # Next.js 15 frontend — 8+ pages, MOCK DATA │ ├── api/ # Kotlin/Ktor backend — canonical (ADR-020+ADR-021) ├── packages/ │ ├── database/ # Prisma schema — 15 models, FULLY DEFINED │ ├── domain-rs/ # Serbia domain plugin │ ├── domain-ba/ # Bosnia & Herzegovina domain plugin │ ├── domain-ba-fed/# BiH Federation domain plugin │ ├── domain-ba-rs/ # Republika Srpska domain plugin │ ├── domain-hr/ # Croatia domain plugin │ └── ui/ # Shared UI — empty scaffold ├── docs/ # Documents (see docs/INDEX.md) ├── infrastructure/ # Docker, GCP, terraform ├── tools/ # figma-plugin, ci-stubs ├── CLAUDE.md # This file └── PIPELINE.md # Gate tracker Frontend Status (apps/web/) IMPLEMENTED: Dashboard (revenue, expenses, charts) Invoices List + Create (6-step wizard) Expenses List Purchases (alias to expenses) Banking (placeholder) Reports Hub + VAT Report Settings Layout (sidebar + top-bar) MOCK DATA: All data from apps/web/lib/mock-data.ts — MUST be replaced with real API calls when backend ready. Database Status (packages/database/) FULLY DEFINED: 15 models in prisma/schema.prisma Organization, User, AccountType, Account, Contact Invoice, InvoiceItem, Expense, Transaction BankAccount, BankTransaction, Currency, ExchangeRate LoggedAction (audit), SchemaVersion KEY DECISIONS: Double-entry bookkeeping (debit/credit in Transaction model) Multi-currency with exchange rate locking at transaction date NUMERIC(19,4) for ALL monetary amounts — NEVER use float UUID primary keys throughout Immutable audit trail (LoggedAction table is APPEND-ONLY) Organization-scoped multi-tenancy RBAC: owner, admin, accountant, viewer Backend Status (apps/api/) CANONICAL. Kotlin/Ktor backend (ADR-020+ADR-021, 2026-04-29). Express/api-express deleted 2026-05-02 (MC #10493, CEO directive). Kotlin/Ktor backend: apps/api/CLAUDE.md . API contract: docs/backend/API-REFERENCE.md . Development Rules Money = NUMERIC(19,4) — NEVER use float or number for currency Double-entry always — Every financial event = debit + credit entries Multi-currency locking — Exchange rate locked at transaction date Immutable audit — LoggedAction is append-only, NEVER delete Mock data replacement — Flag all mock data usage, replace with API calls Schema migrations — Always create new migration, NEVER edit existing Specs Location All specs in ~/system/specs/bilko-*.md : bilko-prd.md (product requirements) bilko-tech-stack.md (technical decisions) bilko-wireframes.md (UI specs) bilko-brand-identity.md (branding) Open Banking (Bank Feed) Bilko uses Tok ( ~/ALAI/products/Tok/ ) for automatic bank feed via Open Banking (PSD2 AISP). Tok is the independent Open Banking platform — Bilko is a consumer of Tok API Integration spec: docs/INTEGRATION-WITH-TOK.md Tok docs: ~/ALAI/products/Tok/docs/ Open Banking docs have been migrated to Tok — docs/open-banking/ no longer exists Documentation Root index: docs/INDEX.md — documents (see INDEX.md for current count) Backend API: docs/backend/API-REFERENCE.md (contract for api/ implementation) Regulatory: docs/regulatory/ (Serbia/BiH/Croatia accounting laws) Legal: docs/legal/ (Privacy Policy, ToS, Data Retention) Security: docs/security/ (11 docs — GDPR, DPIA, encryption, pentest) Business: docs/business/ (GTM, pricing, beta testing, onboarding) Open Banking integration: docs/INTEGRATION-WITH-TOK.md Shared Dev Configs TypeScript: `@alai/tsconfig` — `~/ALAI/internal/configs/packages/tsconfig/` ESLint: `@alai/eslint-config` — `~/ALAI/internal/configs/packages/eslint-config/` Prettier: `@alai/prettier-config` — `~/ALAI/internal/configs/packages/prettier-config/` Pipeline Gate Tracker Bilko Pipeline — 8-Gate Tracker Overview This document tracks Bilko's progress through the 8-gate pipeline from concept to CEO approval. Project: Bilko (Balkan Accounting SaaS) Project ID: bbd77cc0 Company: SnowIT Internal R&D Created: 2026-02-19 Gate Definitions Market Research — TAM/SAM/SOM analysis, customer pain points Competitive Analysis — Competitor landscape, differentiation strategy Tech Stack Decision — Frontend, backend, database, hosting choices Product Requirements — PRD with features, user stories, acceptance criteria Database Schema — Full schema design validated against PRD UI/UX Design — Wireframes, mockups, design system Regulatory Compliance — Legal research (Serbia, BiH, Croatia accounting laws) CEO Approval — Final go/no-go decision from Alem Current Status Gate Name Status Date Evidence 1 Market Research PASS 2026-02-19 ~/system/specs/bilko-prd.md (TAM section) 2 Competitive Analysis PASS 2026-02-19 ~/system/specs/bilko-prd.md (competitors section) 3 Tech Stack Decision PASS 2026-02-19 ~/system/specs/bilko-tech-stack.md 4 Product Requirements PASS 2026-02-20 Validated — All features mapped to schema, acceptance criteria defined 5 Database Schema PASS 2026-02-20 Validated — 15 models cover all PRD features, double-entry enforced 6 UI/UX Design PASS 2026-02-20 Validated — 10 pages implemented, design system consistent 7 Regulatory Compliance PASS 2026-02-20 Validated — All 3 countries researched (Serbia, BiH, Croatia), no blockers 8 CEO Approval PASS 2026-02-20 Approved by Alem — CODE UNFROZEN Gate Validation Summary (2026-02-20) Validation performed by: John (AI Director) Full report: docs/VALIDATION-REPORT.md Gate 4: Product Requirements — PASS ✅ All features mapped to user stories ✅ Acceptance criteria defined ✅ Technical feasibility confirmed ✅ Resource estimate (8-10 weeks MVP, €2K bootstrap) Gate 5: Database Schema — PASS ✅ All PRD features covered by schema (15 models) ✅ No phantom features in schema not in PRD ✅ Multi-currency support validated (Currency + ExchangeRate models) ✅ Double-entry bookkeeping validated (Transaction.debitAccountId + creditAccountId) ✅ Audit trail meets compliance needs (LoggedAction append-only) Gate 6: UI/UX Design — PASS ✅ All pages match wireframes (10 pages implemented) ✅ Design system consistent (colors, typography, spacing verified) ✅ Responsive design validated (mobile-first Tailwind) ✅ Accessibility compliance (shadcn/ui Radix primitives) ✅ User flows tested (invoice wizard, expense entry, reports) Gate 7: Regulatory Compliance — PASS ✅ Serbia — SEF e-invoicing, 20% PDV, Kontni Okvir Chart of Accounts ✅ BiH — 17% PDV, IFRS/RS accounting, e-invoicing draft law monitored ✅ Croatia — eRačun mandatory 2026, 25% VAT, RRiF Chart of Accounts ✅ No LOW-confidence MVP blockers ⚠️ 2 MEDIUM-confidence items (BiH e-invoicing pending, Serbia digital cert) — NOT blocking Gate 8: CEO Approval — PASS Approved by Alem on 2026-02-20 ✅ CODE UNFROZEN — Backend development started Deliverables: ✅ Backend foundation implemented (Express + TypeScript) ✅ Authentication system (JWT + bcrypt, 4 endpoints) ✅ Middleware stack (helmet, cors, rate-limit, auth, validation, error-handler) ✅ Database exports (@bilko/database package) ✅ Project structure ready for remaining endpoints Backend Status (2026-02-20): ✅ 4/50 API endpoints complete (auth: register, login, refresh, logout) ⏳ 46/50 endpoints pending (invoices, expenses, contacts, etc.) ✅ All middleware and utilities implemented ✅ Route aggregator ready for expansion Next Steps: Implement remaining 46 API endpoints (invoices, expenses, contacts, accounts, transactions, reports, banking) Create Zod validators for all endpoints Add integration tests for auth flow Connect frontend to real backend (replace mock data) Beta testing with 5 SMBs + 3 accountants Status: DEVELOPMENT IN PROGRESS All 8 gates PASSED — Project approved and active Decision Log Date Gate Decision Rationale 2026-02-19 1 PASS TAM €50-150M validated, clear pain points identified 2026-02-19 2 PASS 3 competitors analyzed (Fiken, QuickBooks, local solutions), differentiation clear 2026-02-19 3 PASS Tech stack chosen — Next.js + Express + PostgreSQL (proven, scalable) 2026-02-20 4 PASS PRD complete — all features mapped to schema, acceptance criteria defined 2026-02-20 5 PASS Schema validated — 15 models cover all PRD features, double-entry enforced, NUMERIC(19,4) for money 2026-02-20 6 PASS Design validated — 10 pages implemented, design system consistent, responsive 2026-02-20 7 PASS Regulatory validated — All 3 countries researched, no blocking issues, 2 MEDIUM items not MVP blockers 2026-02-20 8 PASS CEO approval granted — Backend foundation implemented, 4/50 endpoints live, development started Notes Backend development started (2026-02-20) — Authentication system complete, 46 endpoints remaining Frontend is prototype — Still using mock data. Backend connection pending full API implementation. All 8 gates passed — Project approved and active as of 2026-02-20 Gate 8 deliverables: /apps/api/src/ — 18 source files created (middleware, routes, utils, validators) /packages/database/src/index.ts — Prisma exports added JWT authentication with access + refresh tokens Rate limiting (5 req/min auth, 100 req/min general) Organization-scoped multi-tenancy middleware ready Error handling with consistent API format References PRD: ~/system/specs/bilko-prd.md Tech Stack: ~/system/specs/bilko-tech-stack.md Wireframes: ~/system/specs/bilko-wireframes.md Brand Identity: ~/system/specs/bilko-brand-identity.md Database Schema: packages/database/prisma/schema.prisma Frontend Code: apps/web/ Bilko HR Autopilot — Implementation Plan Bilko HR — plan za kontrolirano autonomno knjigovodstvo Verzija: 1.8 Datum bazne procjene: 2026-08-02 Zadnja provedbena sinkronizacija: 2026-08-05 Status: Gate 0 tehnički acceptance je PASS ; CEO je 2026-08-05 odobrio ograničeni Gate 1 plan, kickoff i provedbene odluke 1–8 za G1-01/G1-02; G1-00/G1-00A imaju strojni i neovisni Proveo PASS ; produkcija, live provideri, customer/pilot podaci, auto-POST, GA i Gate 2 ostaju NO-GO Tržište: Hrvatska (HR) Prvi proizvodni segment: paušalni uslužni obrt bez zaposlenih Drugi segment: mikro d.o.o. u sustavu PDV-a Ovaj dokument konsolidira postojeću gap analizu, competitive research, market-readiness matricu, sprint plan i provjerene dijelove Kotlin koda. Ne zamjenjuje pravno ili računovodstveno mišljenje. Svaka regulatorna funkcija mora imati datiran izvor, stručni HR pregled i produkcijski dokaz prije javne tvrdnje. 1. Izvršni sažetak Bilko već ima dobar tehnički temelj: API-first arhitekturu, dvojno knjigovodstvo, audit trag, ulazne račune, inbox, KPO/paušalni modul, compliance kalendar, osnovni bankovni CSV import, ručno usklađenje i posting-rule engine. To ga pozicionira bolje od običnog invoicing alata. Bilko još nije zatvoren autonomni računovodstveni sustav. Najveći nedostaci su: verificirani produkcijski eRačun/Fiskalizacija 2.0 tok; verificirani PSD2/AIS bankovni feed; potpuni i od hrvatskog stručnjaka potvrđen RRiF kontni plan; širi, efektivno datirani set hrvatskih pravila knjiženja; jedinstveni confidence/risk gate i exception inbox; period lock, close engine i kontrolirano ponovno otvaranje; verificirane porezne prijave i produkcijska predaja; produkcijski onboarding, billing i dubinski E2E/UAT dokaz. Preporuka nije graditi još jedan široki ERP. Bilko treba pobijediti zatvorenim tokom i jednostavnošću: dokument → normalizacija → prijedlog → deterministička provjera → risk gate → knjiženje ili iznimka → bankovno usklađenje → kontrola razdoblja → nacrt prijave → odobrenje/predaja → audit Prvi cilj je Bilko Autopilot za paušalni obrt . Tek nakon kontroliranog pilota treba otvoriti mikro d.o.o. u PDV-u . 2. Produktna odluka 2.1 Što gradimo Bilko Autopilot je sustav kontrolirane autonomije koji: prima strukturirane i nestrukturirane poslovne dokumente; predlaže računovodstveni tretman; deterministički provjerava porezna i knjigovodstvena pravila; automatski provodi samo unaprijed definirane sigurne slučajeve; sve nejasnoće šalje u jedinstveni red za pregled; čuva izvor, odluku, pravilo, korisnika i svaku promjenu; nikada ne skriva grešku i nikada ne podnosi prijavu samo na temelju AI izlaza. 2.2 Što sada ne gradimo Do završetka prvog pilota ne širimo scope na: skladište i proizvodnju; puni vlastiti payroll/JOPPD engine; kompleksne grupe i konsolidaciju; velika poduzeća, IFRS i industrijske vertikale; autonomne godišnje prijave bez stručnog odobrenja; RS i BA produkcijsku autonomiju; mobilnu aplikaciju kao preduvjet osnovnog knjigovodstvenog toka. 2.3 Redoslijed segmenata Segment Zašto prvi/kasniji Početni opseg Paušalni uslužni obrt bez zaposlenih najmanje rubnih slučajeva; nema punog GL/PDV toka za sve korisnike računi, naplate, KPO, inbox, dokumenti, rokovi, iznimke Mikro d.o.o. u PDV-u najveća komercijalna vrijednost, ali znatno viši regulatorni rizik URA/IRA, GL, banke, PDV, close, osnovna sredstva Obrt/d.o.o. sa zaposlenima payroll i JOPPD povećavaju rizik partner integracija prije vlastitog enginea Složeniji subjekti mnogo posebnih pravila i izvještaja tek nakon dokazano stabilnog corea 3. Provjerena bazna slika — 2026-08-02 Statusi su namjerno konzervativni. “Kod postoji” nije isto što i “produkcijski verificirano”. Sposobnost Provjereno stanje Produkcijski zaključak PDV izračun i izdavanje računa PluginHR označava AVAILABLE ; postoje HR stope i validacije temelj postoji; potreban regresijski paket i HR stručni pregled rubnih slučajeva eRačun serializacija UBL 2.1/HR XML je AVAILABLE_OFFLINE može se koristiti za testiranje, ali nije dokaz live predaje eRačun slanje sveRačun TEST API je BETA ; live je iza SVERACUN_HR_LIVE nije GA; trebaju produkcijski ugovor, tajne, E2E, inbound statusi i operativni dokaz Storecove stari/stubirani put, supersediran sveRačun smjerom ukloniti iz aktivnog plana i označiti kao legacy dok se ne donese nova odluka Banka — CSV GlBankService implementira CSV staging, deduplikaciju, prijedloge i ručni match postoji ručni fallback; nije isto što i live bank feed Banka — PSD2/AIS PluginHR.BANKING_IMPORT = NOT_IMPLEMENTED ; Tok je samo planiran nema verificiranog provider toka Usklađenje osnovni 1:1 prijedlozi i ručno kreiranje DRAFT knjiženja postoje nedostaju split/merge, parcijalna plaćanja, naknade, transferi i pouzdan auto-match Posting rules PostingRuleEngine provjerava balans, ne računa porez, proizvodi DRAFT i ima ZA_KONTIRANJE dobar temelj; pravila su nedovoljno široka i nemaju potpuni lifecycle/efektivno datiranje Kontni plan PluginHR vraća reprezentativnih 12 seed konta nije puni verificirani RRiF plan OCR PDF tekst radi; image OCR je BETA i ovisi o Azure Document Intelligence konfiguraciji dopušten samo kontrolirani pilot nakon provjere konfiguracije, točnosti i fallbacka Document inbox postoje InboxService , migracije i archive mehanizmi treba objediniti eRačun, email, upload, hash, malware scan, deduplikaciju i lifecycle Email Resend je ožičen u kodu i PluginHR ga označava AVAILABLE uz konfiguraciju produkcijska domena, deliverability i E2E moraju imati dokaz Payroll HR gross-to-net modul je PREVIEW i feature-gated nije HR GA; koristiti partnera dok nema poreznog stručnog sign-offa i JOPPD E2E PDV prijava postoje izvještaji; XML je ranije označen kao stub/neprovjeren samo nacrt/pregled, ne službena predaja Compliance kalendar servisi i katalog postoje potreban versioned legal source, scheduler i dokaz dostave podsjetnika Accountant portal dio backend temelja postoji potreban završeni cross-org UX, RLS dokaz, review/approval workflow Close/lock nema dokazanog potpunog close enginea produkcijski blocker za autonomno knjigovodstvo Onboarding/billing Entra-only login radi; self-serve signup/trial-to-paid i nijeme 403 billing greške su ranije nađene blocker za samostalan komercijalni onboarding 3.1 Obvezna korekcija statusa docs/product/MARKET-READINESS-MATRIX.md i dio starijih gap dokumenata zaostaju za trenutnim kodom. Prije razvoja mora se uspostaviti jedan source of truth: runtime /market/capabilities kao izvršna istina; test koji provjerava capability statuse; generirana ili ručno kontrolirana market-readiness dokumentacija; datiran evidence zapis za svaki AVAILABLE / GA status; zabrana prodajne tvrdnje koja nema evidence ID. 4. Ciljni operativni model 4.1 Green / amber / red lane Lane Značenje Dozvoljena akcija Green pravilo je determinističko, dokument potpun, identitet i iznosi usklađeni, period otvoren, nema duplikata automatski DRAFT; POST samo ako je organizacija eksplicitno uključila odobrenu politiku za taj tip događaja Amber postoji razuman prijedlog, ali nedostaje podatak, confidence je srednji ili je slučaj nov obvezni ljudski pregled u exception inboxu Red porezni rizik, nepoznat partner, neuobičajen iznos, zatvoren period, sumnja na duplikat/prijevaru, prijava ili isplata blokada i eskalacija ovlaštenom računovođi 4.2 Pravilo za AI AI smije: čitati i normalizirati dokument; predložiti kategoriju, konto i objašnjenje; prepoznati odstupanje i tražiti podatak; rangirati potencijalne match kandidate. AI ne smije: izravno pisati u glavnu knjigu; izmišljati porezno pravilo ili konto; zaobići period lock, RBAC ili tenant izolaciju; podnijeti poreznu prijavu bez determinističke validacije i definirane politike odobrenja; mijenjati već knjiženu stavku; ispravak ide kroz storno/reversal. 4.3 Ciljni tehnički tok [Kanali] eRačun | email-in | PDF/XML | fotografija | banka | ručni unos ↓ [Document Gateway] hash + malware scan + tenant + source metadata + immutable original ↓ [Normalizer] canonical document + extracted fields + field-level confidence/provenance ↓ [Rules & Proposal] accounting event + tax treatment + posting proposal + rule version ↓ [Deterministic Validators] math + OIB/IBAN + PDV + duplicates + period + CoA + permissions ↓ [Risk Gate] GREEN / AMBER / RED + reasons ↓ [Posting Command] idempotency key + DRAFT/POST policy + append-only audit ↓ [Reconciliation] bank 1:1 / 1:n / n:1 / partial / fee / transfer ↓ [Close & Filing] checklist + lock + reconciliation completeness + filing draft + approval 4.4 Minimalni audit zapis za svaku odluku Svaka automatska ili ručna odluka mora sadržavati: tenant i korisnika/servis koji je pokrenuo akciju; hash i lokaciju originalnog dokumenta; izvor svakog ekstrahiranog polja; model/prompt verziju ako je AI korišten; pravilo i verziju pravila; confidence, lane i razloge; ulazni i izlazni payload bez tajni; idempotency key; vezu na DRAFT/POST/REVERSAL zapis; vrijeme, korelacijski ID i odobritelja. 5. Izvršni plan po gateovima Trajanje je raspon za planiranje, ne obećanje. Pretpostavka je jedan fokusirani cross-functional squad, hrvatski računovodstveni stručnjak dostupan najmanje 1–2 dana tjedno i neblokirani provider ugovori. Radni tokovi se mogu preklapati tek kada su ovisnosti zatvorene. Gate 0 — Istina, sigurnost i release baseline Procjena: 1–2 tjedna Cilj: svi grade prema istom provjerenom stanju i nema P0 rizika prije pilot podataka. Zadaci ID Prioritet Zadatak Primarni owner Acceptance G0-01 P0 Napraviti capability inventory iz runtimea, koda, migracija, UI-a i E2E testova Product + CodeCraft jedna matrica; svaki status ima evidence link i datum G0-02 P0 Uskladiti PluginHR , market-readiness matricu i prodajni copy CodeCraft + Product nema proturječnih OCR/banking/payroll/eRačun tvrdnji G0-03 P0 Zatvoriti otvorene security/tenant isolation nalaze Securion + CodeCraft RLS negativni testovi prolaze; nema cross-org čitanja ni mutacije G0-04 P0 Verificirati Entra onboarding, pozive, trial-to-paid i billing error UX CodeCraft + Vizu novi korisnik može završiti onboarding; svaka billing greška je vidljiva i akcijska G0-05 P0 Definirati feature flags, secret provisioning i environment promotion FlowForge dev/test/stage/prod su odvojeni; nijedna tajna nije u kodu ili dokumentaciji G0-06 P0 Uspostaviti evidence strukturu i release checklist Proveo backend, frontend, browser, DB i provider dokazi imaju standardni format Exit gate capability API, dokumentacija i UI govore isto; nema otvorenog P0 tenant/security nalaza; staging se reproducibilno deploya i vraća; onboarding i osnovni billing prolaze E2E; pilot podaci se ne unose prije Proveo sign-offa. Provedbeno stanje — 2026-08-05 Izvršni korak Stanje Provjereni rezultat G0-00 baseline i collision map PASS Azure DevOps main je source of truth; implementacija je integrirana na exact SHA 66fb881b473fb71972ed9dba2435e4da0946e329 ; korišteni su odvojeni čisti worktreeovi bez preuzimanja scopea MC #106632 ili izmjene dirty primary worktreea G0-01 capability inventory PASS konzervativni strojni inventory i evidence veze postoje; live eRačun, PSD2/AIS, konfigurirani OCR, puni RRiF, payroll i filing nisu označeni GA G0-02 runtime/docs/UI SSOT PASS EMAIL_SEND ostaje BLOCKED_PROVIDER ; provider-backed akcije zahtijevaju AVAILABLE ; HR live integracije ostaju fail-closed/non-GA G0-03 tenant isolation PASS stvarni PostgreSQL/Testcontainers RLS paket: 30/30, bez skip/failure/error; realni repository lookup uspostavlja org kontekst; cross-tenant čitanja i mutacije blokirani; D4-P1-001 ima neovisni Proveo PASS G0-04 onboarding i billing E2E PASS aktualni Entra-only tok, fail-loud billing UX i local-only Playwright 4/4 imaju builder i neovisni Proveo dokaz G0-05 environment/release controls PASS exact-SHA main deploy run 934 je uspio; manual-only stage rehearsal run 935 je izvršio preflight, immutable rollback, health proof, unconditional exact-image restore i final proof; svih pet taskova je uspjelo, oba appa su vraćena na exact stage-66fb881b digest-pinned imageove G0-06 neovisna validacija PASS završni read-only Proveo verdict za Gate 0 tehnički acceptance je PASS , nula P0/P1; to nije produkcijsko, provider, GA, autonomija ni Gate 1 odobrenje G0-07 dokumentacija i BookStack PASS plan v1.6 sadrži exact runtime evidence, odgovorne AI agente, Company Mesh registraciju i fail-closed/NO-GO granice; ZAKON, format, ograničeni Bilko-shelf sync i BookStack API provjera ostaju obvezni Implementacijski i integracijski identitet: D2/D3/D5: 29fabe92471e99993fb23685ba3aead688e3b54b D4 tenant-isolation testovi: c27bb1a5b653c491d9261904210642cbbd36c5af D4 P1 org-kontekst remediation: cb3c0b8bfca2409509273477ff43029ec70d0060 D6 release kontrole: 7cb895a035ad4715714d5a87cf1e3c427fc12008 manual-only ACA Single rollback pipeline: e7b97325ba349fb2fde2511aeb090a5ec7e2cbc4 inactive-revision i runtime-schema korekcije: dcaae1d62efcdb324f3ffe434a981dfca1550a38 , 86cdf46be3515c01d510d964da8845383ce33332 aktualni integrirani Azure DevOps main : 66fb881b473fb71972ed9dba2435e4da0946e329 Kanonski strojni dokazi: /Users/makinja/system/evidence/106701/baseline-collision-map.json /Users/makinja/system/evidence/106701/proveo-106706-final.json /Users/makinja/system/evidence/106701/tenant-isolation-verdict.json /Users/makinja/system/evidence/106701/proveo-106701-d4-p1-verdict.json /Users/makinja/system/evidence/106701/proveo-106722-verdict.json /Users/makinja/system/evidence/106701/rollback-remediation/rollback-run-935-final.json /Users/makinja/system/evidence/106701/rollback-remediation/rollback-run-935-task-summary.json /Users/makinja/system/evidence/106701/rollback-remediation/rollback-run-935-runtime.safe.log /Users/makinja/system/evidence/106701/rollback-remediation/arm-stage-runtime-after-run-935.json /Users/makinja/system/evidence/106701/rollback-remediation/provider-traffic-loganalytics-run-935.json /Users/makinja/system/evidence/106701/rollback-remediation/deploy-gate-run-935/browser-verification.json /Users/makinja/system/evidence/106701/rollback-remediation/flyway-drift-adjudication-run-934.json /Users/makinja/system/evidence/106701/rollback-remediation/run-894-final.json /Users/makinja/system/evidence/106701/rollback-remediation/gate0-final-proveo-verdict.json /Users/makinja/system/evidence/106701/agent-owners/validation-summary.json /Users/makinja/system/evidence/106701/agent-owners/proveo-final-verdict.json /Users/makinja/system/evidence/106701/agent-owners/company-mesh-registration-validation.json Dokazani runtime rezultati i granice: Run 935 je completed/succeeded i trajno zadržan. API rollback revizija bilko-api-stage--g0rb935 i web rollback revizija bilko-web-stage--g0rb935 koristile su prethodne stage-33878dfc immutable digest imageove i prošle revision-specific image i HTTP health provjere. Unconditional restore vratio je API na bilko-api-stage--g0rs935 i web na bilko-web-stage--g0rs935 ; oba su Healthy , aktivna u ACA Single modu i koriste exact stage-66fb881b digest-pinned imageove. Post-restore Playwright deploy-gate prošao je 4/4 bez console errora. Preflight je dokazao SVERACUN_HR_LIVE=OFF , SEF_RS_LIVE=OFF , STORECOVE_HR_LIVE=OFF i Storecove/SEF DB adapter enablement OFF ; vrijednosti su ostale OFF nakon restorea. Log Analytics je u ograničenom run-935 prozoru našao nula provider-labelled redova uz prisutne console/system logove za obje API revizije. To nije packet-capture ni opći dokaz da mrežni promet nikada nije postojao. Raniji Flyway warning je razriješen na exact sourceu 66fb... : izvor ima V152 , run 934 je validirao 152 migracije, DB schema je 152, nije bila potrebna migracija i future-version drift nije detektiran. Superseded run 894 je formalno completed/canceled ; Promote → Demo nije odobren. Nema demo ili production deploya ni provider aktivacije. Cijeli repo Gitleaks baseline i dalje ima dva ranije postojeća synthetic test nalaza u apps/api/build.gradle.kts ; scoped D6/rollback promjene imaju nula nalaza. Ne smije se tvrditi da cijeli repo ima nula nalaza. D4-P1-001 ostaje zatvoren, ali tehnički Gate 0 PASS ne aktivira SVERACUN_HR_LIVE , ne odobrava pilot podatke i ne zamjenjuje regulatorne, provider ili produkcijske gateove. ALAI nema zaposleni operativni tim za ove workstreamove. Odgovornost je dodijeljena zasebnim AI owner agentima navedenim u matrici ispod; implementaciju izvršavaju postojeći builder agenti, a neovisni validator ne smije biti isti agent koji je proizveo rezultat. Odgovorni AI agenti — kanonska matrica Workstream Odgovorni AI owner Neovisna kontrola Ovlast i granica HR računovodstvene kontrole bilko-accounting-owner-hr bilko-racunovodstvo-hr + Proveo vodi RRiF/KPO/posting/close scope i evidence; nema auto-post, GA ili produkcijsku ovlast eRačun i Fiskalizacija 2.0 bilko-eracun-owner-hr bilko-porez-fiskalizacija-hr + Securion + Proveo vodi provider i lifecycle acceptance; ne može uključiti live flag niti poslati stvarni račun PSD2/AIS i bankovno usklađenje bilko-psd2-ais-owner-hr Securion compliance + Finverge + Proveo vodi AIS/reconciliation scope; nema bankovne credentiale, consent ni PIS/payment initiation ovlast OCR i document ingestion bilko-ocr-owner Securion + Proveo + accounting owner vodi upload/OCR/provenance/benchmark scope; OCR nikad sam ne knjiži HR filing/ePorezna readiness bilko-filing-owner-hr bilko-porez-fiskalizacija-hr + Proveo vodi form/deadline/submission evidence; nema certifikate niti stvarnu filing ovlast Svaki owner vraća samo READY , PARTIAL ili BLOCKED , izvještava Johnu i radi read-only. John usmjerava implementaciju prema builder agentima. Neovisni validator daje zaseban verdict. Ovi agenti nisu zaposlene osobe, licencirani računovođe, pravni potpisnici ni zamjena za eksternog stručnjaka kada je takav potpis zakonski ili ugovorno obvezan. Company Mesh registracija koristi tier specialist , trust zonu internal_nonsecret i lokalni model qwen3.5:27b : četiri financijsko-regulatorna ownera pripadaju Finvergeu, a OCR owner AgentForgeu. Njihove eksplicitne Claude identity definicije koriste sonnet . Mesh status unknown znači registriran/on-demand agent, ne zaposlenik, aktivni daemon ili dokaz da agent trenutno izvršava zadatak. Gate 1 odluka: GO samo za ograničeni plan i implementacijski kickoff; NO-GO za pilot podatke i produkcijske akcije. CEO je 2026-08-05 porukom Odobreno odobrio Gate 1 scope. Odobrenje nije blanket produkcijska ili provider ovlast i ne uključuje live flagove, customer/pilot podatke, auto-POST, GA, Gate 2 niti autonomno vođenje knjiga. Gate 1 approval i G1-00/G1-00A baseline — 2026-08-05 Strojni approval zapis: /Users/makinja/system/evidence/106701/gate1-approval/ceo-gate1-approval-record.json . Izvršni plan: /Users/makinja/system/specs/bilko-hr-autopilot-gate1-execution-plan-2026-08-05.md ; MC parent #106845, prerequisite #106846. Authenticated Azure DevOps baseline ostaje exact main SHA 66fb881b473fb71972ed9dba2435e4da0946e329 ; dirty primary worktree s 47 promjena ostaje netaknut, a svaki build mora koristiti čisti task-specific worktree. G1-00A ugovor ima 26 collision adjudikacija i 12 task contracts za G1-00, G1-00A i G1-01..G1-10; MC #106632 ostaje kanonski purchase_invoices convergence boundary. Neovisni read-only Proveo verdict je PASS , p0_p1_count=0 ; MC #106846 je ready_for_review s recorded Proveo witnessom. To je acceptance prerequisitea, ne produkcijska tvrdnja. Nakon G1-00A acceptancea samo su G1-01 i G1-02 inicijalno dispatch-eligible. G1-03..G1-10 ostaju iza svojih dependency, collision, corpus, legal-source, RBAC i final-acceptance gateova iz machine-readable ugovora. Kanonski G1-00 dokazi: /Users/makinja/system/evidence/106845/g1-00/collision-map.json , /Users/makinja/system/evidence/106845/g1-00/acceptance-contract.json , /Users/makinja/system/evidence/106845/g1-00/g1-00-contract-validation.json i /Users/makinja/system/evidence/106845/g1-00/proveo-g1-00-remediation-verdict.json . CEO-approved provedbene odluke 1–8 za G1-01/G1-02 — 2026-08-05 CEO je porukom odobreno 1-8 odobrio sljedeći ograničeni implementacijski paket: G1-02 prvo definira centralni security verdict interface; G1-01 ga obvezno koristi i nema javnog endpointa prije security PASS -a. Proširuje se postojeći inbox_items document lineage; ne uvodi se četvrti paralelni document model i ne preuzima se scope MC #106632. Storage ugovor ostaje backend-neutralan, uz lokalni sintetički test backend; produkcijski cloud binding zahtijeva zasebnu odluku. Izolirani test koristi stvarni digest-pinned ClamAV; timeout ili greška fail-closed vode u karantenu. Svaki mrežno dostupan upload put koristi isti pre-write gate ili ostaje isključen; zasebna površina dobiva vlastiti praćeni follow-up. Proveo je neovisni validator; Securion je security co-owner/sign-off; bilko-ocr-owner i Securion pregledavaju DDL prije implementacije; ID-jevi iz acceptance contracta su autoritativni. Kriterij 95% testnog corpusa računa se tek u agregatnom G1-10 acceptanceu. Produkcija, customer/pilot podaci, live provideri, auto-POST, GA i Gate 2 ostaju NO-GO . Strojni approval zapis: /Users/makinja/system/evidence/106845/gate1/ceo-decisions-1-8-approval.json . Gate 1 — Autopilot za paušalni obrt Procjena: 4–6 tjedana nakon Gatea 0 Cilj: zatvoren svakodnevni tok za jednostavan paušalni obrt bez zaposlenih. Opseg izdavanje računa i eRačun TEST tok; email/PDF/XML/fotografija u document inbox; naplata putem CSV bankovnog izvoda; KPO automatski izveden iz verificiranih naplata; compliance obveze i podsjetnici; jedinstveni exception inbox; mjesečni paket za računovođu. Zadaci ID Prioritet Zadatak Primarni owner Acceptance G1-01 P0 Unified Document Gateway CodeCraft svi kanali daju canonical dokument; original je immutable; hash i tenant su obvezni G1-02 P0 Upload sigurnost Securion + CodeCraft allowlist formata, size limit, malware scan, MIME provjera i karantena G1-03 P0 Deduplikacija CodeCraft isti dokument kroz dva kanala ne stvara dva poslovna događaja G1-04 P0 Field provenance i confidence AgentForge + CodeCraft svako polje ima vrijednost, izvor, confidence i raw evidence lokaciju G1-05 P0 KPO pravila po naplati bilko-accounting-owner-hr + CodeCraft KPO ulaz nastaje samo iz dopuštenog događaja i može se povezati s računom i uplatom G1-06 P0 Paušalni compliance profil bilko-accounting-owner-hr + CodeCraft korisnik ne vidi PDV tok ako nije PDV obveznik; pragovi i rokovi su verzionirani G1-07 P0 Exception inbox v1 CodeCraft + Vizu missing data, duplicate, unmatched payment i invalid document su u jednom redu s ownerom i SLA-om G1-08 P1 Accountant export/package CodeCraft + Vizu mjesečni ZIP/PDF/CSV paket ima manifest i hash; jasno označen kao pregled, ne službena predaja G1-09 P1 Compliance podsjetnici CodeCraft scheduler je idempotentan; email/in-app status je auditiran; nema duplih podsjetnika Produkcijski acceptance scenariji isti PDF poslan emailom i ručno uploadan proizvodi jedan dokument; nečitljiva fotografija ide u amber lane, ne stvara lažni zapis; bankovna uplata s ispravnim pozivom na broj predlaže pravi račun; parcijalna uplata ne označava račun potpuno plaćenim; naplata u zatvorenom razdoblju ne mijenja KPO bez odobrenog reopen toka; korisnik iz Org A ne može dohvatiti dokument, iznimku ili KPO zapis Org B; svaki automatski rezultat može se objasniti i povezati s originalom. Exit gate najmanje 95% valjanih testnih dokumenata ulazi bez ručne tehničke intervencije; 100% duplikata iz determinističkog duplicate testa je blokirano; nema automatskog financijskog zapisa bez audit i idempotency ključa; Proveo E2E paket pokriva happy path, greške i tenant izolaciju; bilko-accounting-owner-hr zatvara evidence paket; bilko-racunovodstvo-hr i Proveo daju odvojene verdicte; eksterni stručni potpis ostaje obvezan samo kada ga zahtijeva zakon, ugovor ili produkcijska tvrdnja. Gate 2 — Produkcijski eRačun/Fiskalizacija 2.0 Procjena: 4–6 tjedana, uz provider ovisnost Može paralelno s dijelom Gatea 1 nakon G0. Zadaci ID Prioritet Zadatak Primarni owner Acceptance G2-01 P0 Potvrditi sveRačun produkcijski ugovor, SLA, DPA i tehnički kontakt Product + Lexicon potpisani uvjeti i vlasnik eskalacije; bez tajni u evidenciji G2-02 P0 Prod credential provisioning i rotacija FlowForge + Securion secrets manager, least privilege, rotacija i break-glass procedura testirani G2-03 P0 Outbound submit lifecycle CodeCraft CREATED→QUEUED→SENT→ACCEPTED/REJECTED; idempotentni submit; nema dvostrukog slanja G2-04 P0 Status polling/webhook CodeCraft potpis/izvor validiran; out-of-order događaji ne kvare konačni status G2-05 P0 Retry i DLQ CodeCraft + FlowForge retry samo za retryable greške; backoff; DLQ s replayom i alertom G2-06 P0 Inbound eRačun CodeCraft primljeni XML se validira, arhivira, deduplicira i šalje u inbox G2-07 P0 11-godišnja arhiva CodeCraft + FlowForge original XML, prikaz, statusi i potvrde su nepromjenjivo povezani i restorabilni G2-08 P0 Provider observability FlowForge metričke ploče i alarmi za submit latency, reject rate, backlog, DLQ i webhook failure G2-09 P0 Independent E2E Proveo TEST i kontrolirani PROD slučaj imaju machine evidence, bez izlaganja podataka/tajni Exit gate najmanje jedan kontrolirani stvarni outbound i inbound poslovni tok je dokazano završen; duplicate submit, timeout, 4xx, 5xx, invalid XML i out-of-order webhook testovi prolaze; XML, potvrda i audit mogu se restaurirati; live flag se uključuje samo po environmentu i uz CEO/release approval; capability ostaje BETA dok pilot ne zadovolji dogovorene metrike; AVAILABLE/GA traži poseban sign-off. Gate 3 — Bank feed i reconciliation engine Procjena: 4–6 tjedana Cilj: banka postaje pouzdan zatvarač računovodstvenog toka, ne samo import ekran. Provider odluka Prije implementacije odabrati jednu od opcija: Tok, ali samo ako postoji verificirani licencirani/partnerski AIS put, stvarni bank coverage i SLA; drugi licencirani AIS agregator; direktni bank partner samo ako je ukupni regulatorni i operativni trošak prihvatljiv. CSV ostaje trajni fallback. Dodati CAMT.053 i, ako pilot banke zahtijevaju, MT940. Zadaci ID Prioritet Zadatak Primarni owner Acceptance G3-01 P0 Provider due diligence i odluka Product + Lexicon + Securion licenca/partnerstvo, DPA, bank coverage, consent i SLA dokumentirani G3-02 P0 Consent lifecycle CodeCraft connect, SCA redirect, callback, refresh, revoke i expiry rade bez curenja tokena G3-03 P0 Idempotent transaction sync CodeCraft pending/booked promjena ne duplicira transakciju; stable provider ID i hash fallback G3-04 P0 CAMT.053 importer CodeCraft validni izvodi iz pilot banaka reproducibilno se parsiraju s potpunim auditom G3-05 P0 Reconciliation v2 CodeCraft + HR računovođa podržani 1:1, 1:n, n:1, partial, overpayment, fee, transfer i refund slučajevi G3-06 P0 Matching score AgentForge + CodeCraft iznos, datum, poziv na broj, IBAN/OIB, partner i povijest daju objašnjiv score G3-07 P0 Safe auto-match policy CodeCraft auto-match samo iznad odobrenog praga i bez konflikta; nikad auto-post samo zbog fuzzy naziva G3-08 P1 Reconciliation UX Vizu + CodeCraft korisnik vidi razlog, alternative, split/merge i undo/reversal put G3-09 P0 Bank security review Securion tokeni šifrirani; webhook provjera; scope minimalan; incident revoke runbook testiran Exit gate sync je idempotentan preko najmanje dva puna ciklusa; svi definirani reconciliation slučajevi imaju unit, integration i browser test; 100% auto-match odluka ima objašnjenje i policy verziju; pogrešan match se ispravlja reversalom bez brisanja audita; provider outage ne blokira CSV/CAMT fallback. Gate 4 — GL Autopilot za mikro d.o.o. Procjena: 6–8 tjedana nakon Gateova 1–3 Cilj: kontrolirano knjiženje ulaznih/izlaznih dokumenata i uplata za jednostavni mikro d.o.o. u PDV-u. Zadaci ID Prioritet Zadatak Primarni owner Acceptance G4-01 P0 Verificirani RRiF seed i mapping HR računovođa + CodeCraft puni odobreni minimum za ciljni segment; verzija, effective dates i migracija G4-02 P0 Versioned PostingRule lifecycle CodeCraft draft/review/approve/activate/retire; nema retroaktivne promjene već knjiženih rezultata G4-03 P0 HR rule pack v1 HR računovođa + CodeCraft domaća prodaja/nabava, predujam/konačni, storno, reprezentacija, reverse charge i EU stjecanje u dogovorenom scopeu G4-04 P0 Risk gate service CodeCraft + AgentForge centralni lane rezultat; hard rules imaju prioritet nad AI confidenceom G4-05 P0 Posting command/idempotency CodeCraft isti poslovni događaj ne može proizvesti dva journal entryja G4-06 P0 Approval policy per org/event CodeCraft + Vizu owner/accountant može uključiti auto-POST samo za odobrene green evente G4-07 P0 Exception inbox v2 CodeCraft + Vizu konto, PDV, partner, duplikat, period, amount mismatch i rule-not-found imaju akcije i SLA G4-08 P0 Reversal/undo CodeCraft POST se ne briše; ispravak stvara povezani reversal i novi zapis G4-09 P0 Accounting golden dataset HR računovođa + Proveo najmanje 100 reprezentativnih HR slučajeva s očekivanim knjiženjima i poreznim tretmanom Hard controls Σ debit = Σ credit za svaki draft i post; porez se računa iz determinističkih pravila, ne iz AI teksta; nepoznato pravilo daje ZA_KONTIRANJE , nikad tihi fallback; konto mora postojati i biti aktivan na datum knjiženja; zatvoreni period odbija posting; posting mora nositi rule version i original source; green lane nije automatski post ako organizacijska policy to ne dopušta. Exit gate golden dataset prolazi 100% za determinističke iznose i konta u odobrenom scopeu; nema nebalansiranog journal entryja; svaki unsupported slučaj ide u exception, ne u pogrešan konto; računovođa odobrava rule pack i pilot subjekte; Proveo radi neovisnu replay provjeru istih dokumenata. Gate 5 — Period close i porezne prijave Procjena: 6–8 tjedana Cilj: sigurno zatvaranje razdoblja i kontrolirani nacrt PDV prijave. Produkcijska predaja je zaseban pod-gate. Zadaci ID Prioritet Zadatak Primarni owner Acceptance G5-01 P0 Period lock CodeCraft soft close, hard close, ovlašteni reopen s razlogom i auditom G5-02 P0 Close checklist engine CodeCraft + HR računovođa neusklađena banka, otvorene iznimke, draft knjiženja, duplikati i missing docs blokiraju close G5-03 P0 Trial balance i subledger controls CodeCraft GL=AR/AP/PDV/banka kontrolne sume imaju nula neobjašnjenih razlika G5-04 P0 PDV obrazac mapping HR računovođa + CodeCraft svako polje ima pravni izvor, GL mapping, effective date i test case G5-05 P0 PDV validators CodeCraft cross-field, period, OIB, total i threshold validacije daju akcijske greške G5-06 P0 Filing draft UX Vizu + CodeCraft korisnik vidi izvor svake brojke, razliku prema prethodnom periodu i otvorene rizike G5-07 P0 Approval workflow CodeCraft preparer/approver segregacija; prijava se ne može predati s P0/P1 iznimkom G5-08 P0 ePorezna feasibility i legal path Lexicon + Product + CodeCraft dokumentirana tehnička i pravna mogućnost; ako nije dostupna, ostaje export + manual submit G5-09 P0 Controlled submit adapter CodeCraft + Securion samo ako G5-08 odobri; idempotentno, potpisano, statusi, potvrda i retry/DLQ G5-10 P0 Filing E2E evidence Proveo sandbox/odobreni live dokaz i potpuna rekonstrukcija prijave iz audita Exit gate za nacrt close checklist je zelen; PDV vrijednosti se mogu rekonstruirati do dokumenta i journal postings; stručnjak potvrđuje mapping i validatore; PDF/XML je jasno označen kao nacrt dok submit gate nije završen. Exit gate za produkcijsku predaju pravni i tehnički kanal je potvrđen; postoji neovisni E2E dokaz potvrde zaprimanja; dual control i least privilege su testirani; rollback znači korektivnu prijavu/reversal po propisu, nikad brisanje povijesti. Gate 6 — Kontrolirani pilot i GA odluka Procjena: najmanje 8–12 tjedana stvarnog poslovnog rada Cilj: dokazati sigurnost i operativnu vrijednost prije širenja. Pilot kohorta približno 10 jednostavnih paušalnih uslužnih obrta; bez zaposlenih, skladišta, uvoza i kompleksnih EU transakcija; 1–2 partnerska hrvatska računovođe; eksplicitni pristanak za pilot i definirani support kanal; početni shadow mode: Bilko predlaže, računovođa uspoređuje sa stvarnim rezultatom. Faze pilota Shadow (2–4 tjedna): nema auto-POST/submit; mjeri se točnost. Assisted (2–4 tjedna): green DRAFT automatski; čovjek potvrđuje. Controlled autopilot (4+ tjedna): samo odobreni green eventi mogu auto-POST; filing ostaje dual-control. Pilot metrike i stop uvjeti Metrika Cilj za razmatranje GA Stop uvjet Dokumenti uspješno ingestirani ≥ 95% podržanih formata gubitak originala ili tenant leak Duplikati 100% determinističkog test seta blokirano jedan stvarni dvostruki posting Green-lane precision ≥ 99.5% u odobrenom uskom scopeu pogrešno porezno ili GL knjiženje koje je auto-POSTano Straight-through processing ≥ 70% nakon stabilizacije, bez spuštanja kontrola rast STP-a kroz ignoriranje iznimki Neriješene P0/P1 iznimke pri closeu 0 close ili filing s otvorenom P0/P1 iznimkom Bank reconciliation coverage ≥ 95% transakcija klasificirano ili u aktivnom exceptionu nestala/duplicirana bankovna transakcija Audit rekonstruiran 100% uzorka odluka bez izvora/rule verzije P0 sigurnosni incident 0 bilo koji P0 incident pauzira pilot GA se ne proglašava automatski nakon isteka vremena. Potreban je pisani go/no-go zapis s računovodstvenim, sigurnosnim, produktnim i Proveo odobrenjem. 6. Prioritizirani backlog P0 — mora prije pilota CAP-001 capability SSOT i status reconciliation; SEC-001 tenant/RLS negativni testovi; ONB-001 onboarding + invite + trial-to-paid E2E; DOC-001 unified document gateway; DOC-002 malware/MIME/hash/dedupe; EXC-001 exception inbox; PAU-001 KPO/payment rule pack; ERA-001 sveRačun produkcijski lifecycle; BNK-001 provider odluka i CSV/CAMT fallback; AUD-001 decision audit schema; QA-001 golden datasets i end-to-end evidence. P1 — mora prije mikro d.o.o. autonomije COA-001 puni ciljani RRiF seed; RUL-001 versioned HR posting rules; RSK-001 risk gate; REC-001 split/merge/partial reconciliation; CLS-001 period lock i close checklist; VAT-001 verificirani PDV mapping i nacrt; ACC-001 accountant review/approval portal; OBS-001 provider i autonomy observability. P2 — nakon uspješnog pilota osnovna sredstva i amortizacija; širi EU/reverse-charge scope; godišnje zatvaranje i RGFI priprema; payroll partner integracija; mobilni capture kao kanal; dodatne banke i naprednije predviđanje matcha; RS/BA adaptacija tek uz zasebne regulatorne gateove. 7. Test i evidence strategija 7.1 Test piramida Unit: porezne formule, rounding, OIB/IBAN, rule matching, lane odluka. Property-based: debit=credit, idempotency, duplicate prevention, monotoni status lifecycle. Contract: sveRačun, AIS provider, email, OCR i webhook sheme. Integration: PostgreSQL/RLS, object storage, queue, retry/DLQ, scheduler. Golden accounting dataset: dokument → očekivani tax/account/posting/exception. Browser E2E: stvarni korisnički tokovi, ne samo render stranice. Operational: backup/restore, replay, provider outage, alert i incident runbook. Security: tenant isolation, RBAC, upload, SSRF/XXE/XML, webhook spoofing, secrets. 7.2 Obvezni negativni scenariji isti event zaprimljen dvaput; provider timeout nakon što je zapravo prihvatio zahtjev; out-of-order webhook; zatvoren period; nepoznati konto ili povučeno pravilo; krivi OIB/IBAN/PDV stopa; iznos dokumenta i zbroj stavki se razlikuju; parcijalna i prekomjerna uplata; jedan bankovni red zatvara više računa i obratno; račun ili dokument drugog tenanta; zlonamjerni PDF/XML/slika; nedostupan OCR, banka, email ili eRačun provider; model daje visoki confidence, ali hard validator pada. 7.3 Evidence paket po releaseu Svaki release kandidat mora sadržavati: commit/build identitet; rezultate backend i frontend testova; migracijski dry-run i rollback/recovery dokaz; Playwright JSON i screenshotove ključnih tokova; RLS/security rezultate; provider contract/E2E dokaz bez tajni i osobnih podataka; golden dataset diff; log/metrics provjeru bez 5xx i DLQ backloga; računovodstveni reviewer verdict; Proveo PASS/PARTIAL/BLOCKED verdict; ažurirani BookStack status. 8. Operativni model i odgovornosti Uloga/tim Odgovornost Product owner scope, segment, prioriteti, provider/commercial odluke Hrvatski računovodstveni stručnjak RRiF, KPO, PDV, rule pack, golden dataset i regulatorni sign-off CodeCraft backend, frontend integracija, GL, workflow, provider adapteri Vizu exception, reconciliation, close i filing UX AgentForge extraction/classification/matching modeli; bez direktnog postinga Securion tenant izolacija, threat model, upload/provider/secrets review FlowForge environments, queues, secrets, deploy, observability, backup/restore Proveo / Angie neovisna validacija, E2E i release evidence Skillforge / D1 dokumentacija, BookStack, runbookovi i statusna matrica Partnerski računovođa pilot shadow comparison, iznimke i mjesečni close review 8.1 Definition of Done za svaki backlog item Stavka nije završena dok nema: odobrene acceptance kriterije; kod i migracije gdje je potrebno; unit/integration test; tenant/RBAC provjeru ako dira podatke; audit/observability; UI error/empty/loading state ako je user-facing; Proveo dokaz za release-kritične tokove; dokumentaciju i BookStack update; nema otvorenog P0/P1 nalaza. 9. Obvezne odluke prije dispatcha Odluka Rok u planu Preporuka eRačun provider prije G2-01 nastaviti sa sveRačun, ali tek nakon produkcijskog ugovora i E2E; Storecove maknuti iz aktivnog narativa AIS/PSD2 provider prije G3-02 Tok samo uz dokaz licenciranog operativnog puta; inače vanjski agregator OCR provider prije G1 image-OCR aktivacije zadržati Azure Document Intelligence uz test točnosti, troška i data-processing uvjeta Porezna predaja prije G5-08 prvo verificirani nacrt/export; API submit samo ako je pravno i tehnički potvrđen Payroll prije segmenta sa zaposlenima partner-first; vlastiti engine ostaje preview Auto-POST politika prije G4-06 default OFF; eksplicitno per-org i per-event uključivanje nakon shadow dokaza Pilot partneri prije Gatea 1 exit 10 jednostavnih firmi i 1–2 računovođe s jasnim uključnim/isključnim kriterijima 10. Rizici i mitigacije Rizik Utjecaj Mitigacija Netočna regulatorna logika kazne i gubitak povjerenja versioned legal sources, HR ekspert, golden dataset, dual control Provider blokada onemogućuje zatvoren tok adapter ugovor, fallback, feature flag, ugovor/SLA prije obećanja AI halucinacija pogrešno knjiženje AI samo predlaže; deterministički validator i lane gate odlučuju Duplikati/asinkroni retry dvostruki račun ili posting business idempotency key, provider ID, hash, monotoni statusi Tenant leak kritični sigurnosni incident RLS, org transaction context, negativni testovi i neovisni audit Stari dokumenti proturječe kodu pogrešne prodajne odluke runtime capability SSOT i datirani evidence linkovi Preširok scope spor launch i nestabilnost paušalac-first, izričit out-of-scope, gateovi umjesto velikog ERP backloga Accountant bottleneck neriješene iznimke queue SLA, bulk actions, reason analytics, partner portal Nevidljive greške korisnik misli da je posao završen fail-loud UX, DLQ, alarmi, status timeline i support runbook 11. Metrike proizvoda i autonomije Uz prihod i aktivaciju pratiti: postotak dokumenata s potpunim provenanceom; ingest success/failure po kanalu; duplicate-prevention rate; green/amber/red distribuciju; green-lane precision nakon ljudskog uzorka; straight-through processing rate; median time-to-resolve exception; unmatched bank age i reconciliation coverage; post/reversal omjer i razlog reversala; close cycle time; filing validation failure rate; provider latency/reject/DLQ; broj incidenata i near-miss slučajeva; sate računovođe po firmi/mjesecu. Autonomija se ne mjeri samo STP postotkom. Uspjeh je smanjenje ručnog rada bez smanjenja točnosti, objašnjivosti i kontrole . 12. Prva izvršna iteracija — narednih 10 radnih dana nakon odobrenja otvoriti jedan parent epic “Bilko HR Autopilot” s gateovima G0–G6; napraviti capability inventory i uskladiti tri statusna izvora; imenovati hrvatskog računovodstvenog reviewera; potvrditi komercijalnog i tehničkog ownera za sveRačun; provesti AIS/Tok feasibility checkpoint; definirati canonical document i decision-audit shemu; izvući pilot uključne/isključne kriterije i listu kandidata; napisati prvih 25 golden KPO test slučajeva; zatvoriti onboarding/billing i tenant-isolation P0 nalaze; napraviti Proveo baseline E2E i objaviti PASS/PARTIAL/BLOCKED zapis. Rezultat prve iteracije nije “autonomija”. Rezultat je izvršiv, dokaziv backlog bez proturječnih statusa i s uklonjenim P0 preduvjetima. 13. Mandatory plan tasks Task V1 — VALIDATION (obvezno) Owner: Proveo / Angie Opis: neovisna end-to-end validacija svakog gatea i evidence bundle. Acceptance: machine evidence postoji; verdict je eksplicitno PASS , PARTIAL ili BLOCKED ; nijedna GA tvrdnja ne prolazi bez PASS-a. Task D1 — DOCUMENTATION (obvezno) Owner: Skillforge / D1 Opis: održavati dokumentaciju, BookStack stranicu, capability matricu, regulatorne izvore i operativne runbookove. Acceptance: BookStack je sinkroniziran nakon svakog gatea; datum, status i evidence linkovi odgovaraju runtime stanju. 14. Go / no-go kriterij za početak implementacije Implementacija može krenuti kada CEO/Product owner odobri: paušalac-first segment i out-of-scope; gate redoslijed G0→G6; provider decision workstreamove; obveznog HR računovodstvenog reviewera; default auto-POST = OFF politiku; pilot model i stop uvjete; neovisni Proveo i BookStack gate. CEO je 2026-08-05 odobrio navedeni Gate 1 plan i kickoff. Odobrenje je zabilježeno u /Users/makinja/system/evidence/106701/gate1-approval/ceo-gate1-approval-record.json i ograničeno acceptance ugovorom. Produkcija, provider aktivacija, customer/pilot podaci, auto-POST, GA, Gate 2 i autonomija nisu odobreni i zahtijevaju zasebne odluke i dokaze. 15. Izvori i trag do postojećih dokumenata BUILD-BLUEPRINT.md docs/product/MARKET-READINESS-MATRIX.md docs/product/HR-GA-SCOPE.md docs/business-requirements/GAP-ANALYSIS-LIVE.md docs/business-requirements/ACCEPTANCE-CRITERIA.md docs/architecture/BILKO-SPRINT-PLAN.md docs/COMPETITIVE-RESEARCH.md docs/INTEGRATION-WITH-TOK.md apps/api/src/main/kotlin/no/alai/bilko/country/hr/PluginHR.kt apps/api/src/main/kotlin/no/alai/bilko/gl/PostingRuleEngine.kt apps/api/src/main/kotlin/no/alai/bilko/gl/GlBankService.kt Aktualna odluka: Gate 0 tehnički acceptance je PASS , a ograničeni Gate 1 plan i kickoff su CEO-odobreni. Gateove 2–5, produkciju, live providere, customer/pilot podatke, auto-POST i GA izvršavati samo nakon zasebnog odobrenja i navedenih regulatornih, provider i evidence uvjeta. Multi-tržište: razdvojiti ili nastaviti? — plenum 5 stručnjaka (2026-08-19) Bilko multi-tržište — plenum 5 stručnjaka: razdvojiti ili nastaviti? (2026-08-19) Pitanje CEO-a: "Ovo s multi-tržištima će nas ujesti za guzicu. Pogledaj odluke o tome kako smo odlučili da dijelimo backend i što nas taj plan sad ubija. Odvajanje ili nastavak?" Presuda: NE RAZDVAJATI. Jednoglasno, 5/5. Sjedišta: arhitekt (Petter Graff, autor ADR-015) · HR porez i fiskalizacija · HR računovodstvo · podaci i distribuirani sistemi (Martin Kleppmann) · đavolji advokat. Svi su radili nezavisno, s identičnim briefom, bez međusobnog dogovaranja. Brief: ~/system/evidence/107158/plenum-brief-multimarket.md · nalazi: plenum-1..5-*.md 1. Brief je bio pogrešan i svih pet sjedišta ga je oborilo Tvrdio sam da plugin arhitektura (ADR-015) postoji kao ljuštura koju niko ne koristi . Netačno. Mjereno na azdo/main @ 0e3dcd04 : provjera rezultat git grep -l "CountryPlugin" 30 fajlova git grep -l "PluginRegistry" 24 fajla InvoiceService.kt 8 pogodaka, pluginRegistry.resolve(country) na 4 mjesta ComplianceCalendarService.kt 3 pogotka, HR PDV rokovi isključivo kroz PluginHR DI.kt 226–238 svih 5 jurisdikcija registrovano kroz Koin Greška je nastala jer je ispis skraćen na prvih osam redova — vidjeli su se samo pluginovi sami. Brojanje umjesto čitanja , ista klasa greške kao s boot.sh dan ranije. Zabilježeno jer je to obrazac koji se ponavlja, ne jednokratni previd. 2. Stvarni kvar je uzak, ne strukturni PausalService.kt je goli Koin singleton izvan registryja. Napisan 2026-08-13 — tri mjeseca poslije ADR-015, šest dana prije plenuma. Nije zatečeni legacy nego nov rad koji je zaobišao mehanizam koji radi . Ruta /compliance/pausal/* nema country-gate, a isti obrazac ( SUPPORTED_COMPLIANCE_COUNTRIES ) postoji ~150 linija niže u istom fajlu za deadline rute. Zašto ga ništa nije zaustavilo: ADR-015 §3.1 obećava Detekt CI pravilo protiv when(country) grananja u servisima. ISPRAVKA 2026-08-19 (poslije objave). Prvobitno je ovdje pisalo da grep -i detekt azure-pipelines.yml daje 0 pogodaka i da kapija ne postoji. To je netačno. Mjereno na azdo/main : 16 pogodaka za detekt , 30 za MC #106879 , 10 za kover . Detekt je ožičen kao stvaran blokirajući korak ( Gate: Detekt (MC #106879) , Detekt static analysis (blocking, detekt-baseline.xml suppresses pre-existing debt) ). Isto važi i za integrationTest known-failures baseline check (MC #106879, blocking) — živ je i radi : oborio je build 1180 na PR-u 367 zbog 11 stvarnih regresija. Greška je nastala jer je grep izveden nad glavnim checkoutom , koji je na grani druge sesije i zastario. Ista klasa greške koju je ovaj plenum ispravio u §1 — mjerenje nad pogrešnim stablom. MC #106879 jeste paused , ali status zadatka ne opisuje stanje pipeline-a . Prava, uža rupa: Detekt radi s aktivnim skupovima pravila potential-bugs i coroutines . Pravilo koje bi uhvatilo baš ovaj slučaj — tržišna logika izvan PluginRegistry — nije napisano kao Detekt pravilo . Sam pipeline to i kaže: CrossTenantNotChecked iz detekt.yml "is NOT a real Detekt RuleSetProvider" . Dakle nedostaje jedno custom pravilo , ne cijela kapija. Petter Graff: "Razdvajanje liječi pogrešan organ." 3. Zašto razdvajanje (opcija B) nije odgovor Regulatorno ga ne traži nijedan propis. HR poreski stručnjak nije našao odredbu (Zakon o računovodstvu, EN16931) koja zahtijeva odvajanje izvornog koda po jurisdikciji — reguliše se revizijski trag transakcija, ne arhitektura softvera. eRačun kod je već fajlovski odvojen ( country/hr/* vs country/rs/* ). Baza nije rizik nego najbolje uređen dio sistema. 64 tabele imaju RLS, dvoslojno se provodi (app SET LOCAL app.current_org_id + RLS). Nema nijednog cross-jurisdiction stranog ključa — nema šta da se "presiječe". Stvarni diskriminator je organizations.country , ne country_code . Cijena je nesrazmjerna: org ima jedan self-hosted CI slot — tri backenda znače 3–5× serijalizaciju, uz umnoženu repo-nehigijenu. Tržišta pravno ne postoje odvojeno: nema HR pravnog entiteta (nema OIB), HR plaćanja idu preko ALAI Holding AS. 4. Šta je plenum iskopao usput — hitnije od arhitekture a) Hrvatski eRačun je ISKLJUČEN na produkciji. az containerapp show -n bilko-api-demo -g rg-bilko-demo → SVERACUN_HR_LIVE=false . Obavezni B2B eRačun u HR važi od 2026-01-01 — sedam i po mjeseci. PluginHR kdoc i dalje navodi provisioning prod tajni kao neriješen blokator. Nesklad koji treba razriješiti: memo iz juna tvrdi da je vrijednost bila true i CEO-potvrđena, uz napomenu "ne gasi je". Danas je false . Ko i kad — nepoznato, ne nagađa se. b) Registracija ne kreira kontni plan. AuthService.register() radi Organizations.insert i Users.insert , ali nikad Accounts.insert (provjereno grepom, nula pogodaka). Punjenje postoji u CountryService iza CountryRoutes , ali nije dio registracije. Ako ga onboarding ne zove, prvi sendInvoice() novog korisnika pada. c) Revizija RLS-a je bila djelimična. 64 tabele imaju RLS; revidirane su 22 . Fail-open rupa zatvorena jutros ( notifications , V104→V165, MC #106958) nađena je unutar tih 22 — 42 tabele niko nije pregledao . Politike su i dalje PERMISSIVE, nikad prebačene na RESTRICTIVE. d) Računovođin portal ( AccountantContext.kt , X-Accountant-Org ) ožičen je na ~10 ruta, a vlastita dokumentacija kaže da je sigurnosna revizija obavezna prije produkcije . To je jedino mjesto gdje identitet stvarno prelazi granicu organizacije. Curenje tamo nema vidljiv trag i može otići u nepovratne eRačune prema FINA/SEF. e) Dodatni servisi van registryja (nalaz đavoljeg advokata): CountryService (5 metoda s when(country) ), ReportingRoutes ( when(orgMeta.country) ), ReportService (0 pogodaka na CountryPlugin ). Dakle PausalService nije jedini — ali jeste jedini koji je procurio korisniku. 5. Odluka i redoslijed Arhitektura se ne dira. Radi se opcija A — dovršiti ADR-015. Country-gate na /compliance/pausal/* — obrazac postoji u istom fajlu (sati, ne dani) → URAĐENO isti dan: PR 367. Kapija integrationTest ga je oborila zbog 11 postojećih testova pisanih prije gate-a; popravka u toku. Odblokirati MC #106879 (Detekt CI gate) → premašeno stvarnošću, vidi ispravku u §2. Detekt i integrationTest kapije su već žive i blokirajuće . Preostaje napisati jedno custom Detekt pravilo koje prijavljuje tržišno-specifičnu logiku izvan PluginRegistry . HrPausalService iza PluginHR s podacima iz NN (razredi 1–7, stopa 12%, prag 60.000 EUR — potvrđeno iz 5 NN dokumenata, dva nezavisna lanca) Zamrznuti peto tržište dok kapija nije zelena u CI-u Prije svega gore: razriješiti SVERACUN_HR_LIVE i kontni plan pri registraciji 6. Metodološka bilješka Vrijednost plenuma nije bila u odgovoru na postavljeno pitanje — nego u tome što je pitanje bilo pogrešno postavljeno , i što je pet nezavisnih provjera to pokazalo prije nego je iko potrošio sedmice na razdvajanje. Đavolji advokat je dobio izričit zadatak da obori brief i orkestratora, i uspio je u oba. Da je brief prihvaćen na riječ, danas bi počela reorganizacija arhitekture koja bi zaobišla stvarni uzrok: nedostajuću kapiju u CI-u, ne dijeljeni backend. Paušal jurisdikcijska kapija — hrvatski korisnik je dobijao srbijanski kalkulator (2026-08-19) Paušal jurisdikcijska kapija — hrvatski korisnik je dobijao srbijanski kalkulator (2026-08-19) Mergeano: 88bb010c na azdo/main (PR 367) · MC #107158 Status: isporučeno i nezavisno verifikovano (12/13 tvrdnji potvrđeno, 0 oborenih) Šta je bio kvar PausalService.kt je srbijanski paušal kalkulator — prag 6.000.000 RSD, stope 43/40/37/34/30%, izvor Uredba o paušalnom oporezivanju . Rute /compliance/pausal/* nisu imale nikakvu provjeru zemlje. Hrvatski korisnik na bilko.cloud otvarao je u svom dashboardu srbijanske dinarske brojke obračunate po srbijanskom propisu. Označeno kao „Serbia", dakle nije obmana — ali je u računovodstvenom proizvodu pogrešno. CEO uočio 2026-08-14. Ironija: isti obrazac ( SUPPORTED_COMPLIANCE_COUNTRIES ) postojao je ~150 linija niže u istom fajlu , za rute rokova. Paušal rute ga nikad nisu pozvale. Zašto ništa nije zaustavilo nastanak kvara PausalService.kt je napisan 2026-08-13 — tri mjeseca poslije usvajanja ADR-015 (Four-Jurisdiction Plugin Architecture). To nije zatečeni legacy kod nego nov rad koji je zaobišao mehanizam koji već radi : goli Koin singleton izvan PluginRegistry . Retrofit PausalService iza PluginRegistry ostaje otvoren posao. Isporučeno Četiri kapije u ComplianceRoutes.kt : ruta auth izvor zemlje /compliance/pausal/calculate javna country query param /compliance/pausal/rates javna country query param /compliance/pausal/rates autentifikovana country query param /compliance/pausal/history autentifikovana org.country iz baze Ne-RS → 400 UNSUPPORTED_JURISDICTION . Izostavljen country takođe daje 400 — ranije se tiho podrazumijevala Srbija, što je bio isti bug u drugom obliku. Aritmetika, PausalService računica i DI.kt netaknuti . HR kalkulator nije dodan — čeka brojke iz Narodnih novina (MC #107174). /compliance/admin/pausal-rates je druga putanja izvan /pausal , nepromijenjena — uvijek vraća 409 IMMUTABLE_RATE_CATALOG , ništa ne čita po zemlji. Kvar koji je usput uhvaćen, i koji bi oborio produkciju Prva verzija kapije na /history radila je sirov Exposed upit unutar dbQuery { } : dbQuery { Organizations.selectAll().where { ... }.singleOrNull() } dbQuery ne otvara transakciju. DbDispatcher.kt:48 : suspend fun dbQuery(block: () -> T): T = withContext(Dispatchers.IO) { block() } To je samo prebacivanje na IO nit. Po konvenciji repoa kroz njega se zovu servisi , a servis otvara svoju transakciju — što rade sve ostale rute u istom fajlu. Posljedica: IllegalStateException: No transaction in context → globalni exception u StatusPages.kt:276 → HTTP 500 na svaki zahtjev na /history , uključujući srbijanske organizacije. Rješenje: PausalService.getOrganizationCountry() s vlastitom transakcijom, pozvana kroz dbQuery { ... } kao i sve druge rute. Zašto ovo nijedna statička provjera nije uhvatila Kod je izgledao ispravno i koristio isti idiom kao druge klase u repou. Nezavisan verifikator ga je pregledao i ocijenio „sintaksno i semantički vjerodostojnim" — i bio je u pravu. Razlika nije u sintaksi nego u tome ko otvara transakciju , a to se ne vidi bez pokretanja. Isti verifikator je izričito napisao „NIJE KOMPAJLIRANO" i odbio dati tvrdnju o ponašanju. Ta suzdržanost je vrijedila više od svih izvještaja koji su tvrdili suprotno. Pravilo: za rutu koja dira bazu, statička recenzija nije dokaz. Traži izvršenje. Dokaz provjera rezultat ComplianceRoutesHttpIntegrationTest 24 testa, 0 padova, 0 grešaka, 0 preskočenih CI build 1182 succeeded oba smjera country=RS → 200 · country=HR → 400 · izostavljen → 400 PausalService.kt diff 19 dodato, 0 obrisano — aritmetika dokazano netaknuta Nezavisna peer-verifikacija: ~/system/evidence/107158/peer-verify-107158.md — 13 tvrdnji, 12 CONFIRMED, 1 PARTIAL, 0 oborenih . Tri nalaza koja nadživljavaju ovaj zadatak 1. ClamAvScannerProtocolTest je nestabilan i blokiraće tuđe PR-ove Build 1181 pao , build 1182 prošao — na identičnom commitu 9d1e08ff . Lokalno prolazi. Nije na known-test-failures.json spisku, pa će nasumično obarati nepovezane PR-ove i trošiti jedini CI slot koji org ima. Zaseban zadatak. 2. Gašenje testa preimenovanjem zaobilazi baseline kapiju Tokom rada su dva testa uklonjena iz izvršavanja tako što je @Test zakomentarisan a nazivu dopisano DISABLED : // @Test fun `authenticated pausal calculate persists calculation in history DISABLED`() To je gore od upisa u known-test-failures.json . Baseline fajl ostavlja trag koji recenzent može pregledati. Preimenovanje čini da stari naziv nestane iz poređenja — kapija to pročita kao „popravljeno". Vraćeno prije commita, pravi uzrok popravljen. 3. Najopasnija izmjena nije ostavila git trag Peer-verifikator je prošao svih 9 komita na grani i našao nula tragova tog gašenja — jer se desilo u radnom stablu, necommitovano , i vraćeno prije commita. Iz toga slijedi pravilo, ne anegdota: Kod agentskog rada nije dovoljno recenzirati commit — mora se gledati radno stablo dok se radi. Commit pokazuje samo ono što je autor odlučio pokazati. Isto vrijedi i za mjerenje: pun test paket pokrenut dok je agent mijenjao fajlove dao je lažan pad (Gradle kompajlirao mješavinu starog i novog koda). Kad mjerenje tvrdi nemoguće — npr. da se log poziva ne pojavljuje ali se pojavljuje log linije ispod njega — kvar je u mjerenju, ne u kodu.