# 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](backend/API-REFERENCE.md) | All 26 API endpoints — method, path, request/response, auth, rate limits | | [Database Schema](backend/DATABASE-SCHEMA.md) | All 19 tables (12 core + 7 compliance) — columns, types, constraints, indexes | | [Authentication](backend/AUTHENTICATION.md) | JWT auth flow — register, login, refresh, logout, middleware | | [Services](backend/SERVICES.md) | External integrations — Sumsub (KYC) `[PRODUCTION]`, Stripe (Cards) `[MOCK]`, Swan `[DEPRECATED]` | | [Currency Rates](backend/CURRENCY-RATES.md) | FX rate source, DB cache/freshness, rate limiting, supported NOK corridors, verification findings | | [Middleware](backend/MIDDLEWARE.md) | Auth, validation, rate limiting, CSRF, error handling | | [Feature Flags](backend/FEATURE-FLAGS.md) | 8 feature flags, 16 tracked features, server/client APIs | ## Frontend | Document | Description | | ------------------------------------------------------ | ------------------------------------------------------------------- | | [Component Inventory](frontend/COMPONENT-INVENTORY.md) | All components — custom, icons, shadcn/ui primitives | | [Pages](frontend/PAGES.md) | All 20 routes — auth, components, data fetching, compliance pages | | [Design System](frontend/DESIGN-SYSTEM.md) | Colors, typography (Fraunces/DM Sans/Geist Mono), spacing, patterns | | [State Management](frontend/STATE-MANAGEMENT.md) | useAuth hook, feature flags, data fetching patterns | | [Landing Pages](frontend/LANDING-PAGES.md) | Marketing site — 9 sections, 12 sub-pages, waitlist API | ## Mobile | Document | Description | | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | [Mobile App](mobile/MOBILE-APP.md) | Expo Router architecture, 8 screens, API client, theme | | [Role-Based UX + Demo User Matrix + BankID Mock](mobile/ROLE-BASED-UX-DEMO-BANKID.md) | Merchant-only Profile UX, seeded demo users, BankID demo-mode behavior — verified against source 2026-07-28 | ## Infrastructure | Document | Description | | -------------------------------------------- | ----------------------------------------------------------------- | | [Deployment](infrastructure/DEPLOYMENT.md) | Docker, Fly.io, 3 deployment configs (MVP/Production/Staging) | | [CI/CD](infrastructure/CI-CD.md) | GitHub Actions pipeline — lint, test, build, e2e, docker (5 jobs) | | [Monitoring](infrastructure/MONITORING.md) | Health checks, container monitoring, gaps identified | | [Environment](infrastructure/ENVIRONMENT.md) | Tech stack, npm scripts, Next.js config, env modes | ## Security | Document | Description | | --------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | [Security Architecture](security/SECURITY-ARCHITECTURE.md) | JWT, cookies, bcrypt, CSRF, rate limiting, input validation | | [Compliance](security/COMPLIANCE.md) | PSD2, AML, GDPR, DORA readiness — 8/100 overall, remediation plan | | [PCI-DSS SAQ-A Readiness](SECURITY-COMPLIANCE/pci-dss-saq-a.md) | Applicability determination + SAQ-A gap list for the (currently disabled) Cards feature | ## Testing | Document | Description | | ------------------------------------------- | ------------------------------------------------------------------- | | [Testing Guide](testing/TESTING-GUIDE.md) | Vitest + Playwright, running tests, mocking, patterns | | [Test Inventory](testing/TEST-INVENTORY.md) | All 14 test files — unit, integration, e2e, regression, performance | ## Quality Assurance | Document | Description | | ----------------------------------------- | ----------------------------------------------------- | | [Validation Report](VALIDATION-REPORT.md) | 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](/ALAI/products/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: 1. **Remittance** — pošalji novac u inostranstvo jeftinije (primatelj NE treba app) 2. **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 1. Amir otvori Drop, tap "Pošalji novac" 2. Odabere: Srbija, mama Jasmina, njen broj računa 3. Unese 2,000 NOK → vidi: primatelj dobije 23,400 RSD, fee 10 NOK (0.5%) 4. Potvrdi, plati sa norveške kartice 5. Mama dobije SMS: "Primili ste 23,400 RSD od Amira" 6. Novac na računu za 1-2 radna dana ### Journey B: QR Payment 1. Amir uđe u Ahmetov kebab shop u Oslu 2. Na kasi je Drop QR naljepnica 3. Amir otvori Drop, tap "Skeniraj" 4. Skenira QR → prikaže se: "Ahmetov Kebab, unesi iznos" 5. Unese 129 NOK, tap "Plati" 6. Ahmet dobije notifikaciju: "Primljeno 129 NOK od Amir" 7. Instant. Bez terminala. Fee 1.29 NOK umjesto 3.55 NOK (Vipps). ### Journey C: Killer Combo 1. Amir šalje 5,000 NOK mami — dobije 25 Drop bodova 2. Plaća kebab 129 NOK QR-om — dobije 1 bod 3. Na 50 bodova: besplatna remittance (no fee) 4. Ahmet (merchant) vidi: "Ove sedmice: 47 transakcija, 12,300 NOK, fee 123 NOK" 5. Ahmet preporuči Drop svim korisnicima → novi korisnici → više remittance --- ## 5. Merchant Onboarding (3 minuta) 1. Vlasnik skine Drop app 2. Tap "Registruj biznis" → unese: naziv, adresa, bank račun 3. KYC: lična karta + org.nummer 4. Dobije QR kod — printaj ili koristi na telefonu 5. Lijepi QR na kasu 6. 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 1. **Money = NUMERIC(19,4)** — NEVER use float or number for currency 2. **Double-entry always** — Every financial event = debit + credit entries 3. **Multi-currency locking** — Exchange rate locked at transaction date 4. **Immutable audit** — LoggedAction is append-only, NEVER delete 5. **Mock data replacement** — Flag all mock data usage, replace with API calls 6. **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 1. **Market Research** — TAM/SAM/SOM analysis, customer pain points 2. **Competitive Analysis** — Competitor landscape, differentiation strategy 3. **Tech Stack Decision** — Frontend, backend, database, hosting choices 4. **Product Requirements** — PRD with features, user stories, acceptance criteria 5. **Database Schema** — Full schema design validated against PRD 6. **UI/UX Design** — Wireframes, mockups, design system 7. **Regulatory Compliance** — Legal research (Serbia, BiH, Croatia accounting laws) 8. **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:** 1. Implement remaining 46 API endpoints (invoices, expenses, contacts, accounts, transactions, reports, banking) 2. Create Zod validators for all endpoints 3. Add integration tests for auth flow 4. Connect frontend to real backend (replace mock data) 5. 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: 1. verificirani produkcijski eRačun/Fiskalizacija 2.0 tok; 2. verificirani PSD2/AIS bankovni feed; 3. potpuni i od hrvatskog stručnjaka potvrđen RRiF kontni plan; 4. širi, efektivno datirani set hrvatskih pravila knjiženja; 5. jedinstveni confidence/risk gate i exception inbox; 6. period lock, close engine i kontrolirano ponovno otvaranje; 7. verificirane porezne prijave i produkcijska predaja; 8. produkcijski onboarding, billing i dubinski E2E/UAT dokaz. **Preporuka nije graditi još jedan široki ERP.** Bilko treba pobijediti zatvorenim tokom i jednostavnošću: ```text 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: 1. runtime `/market/capabilities` kao izvršna istina; 2. test koji provjerava capability statuse; 3. generirana ili ručno kontrolirana market-readiness dokumentacija; 4. datiran evidence zapis za svaki `AVAILABLE`/`GA` status; 5. 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 ```text [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:** 1. 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. 2. 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. 3. 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. 4. 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. 5. Superseded run 894 je formalno `completed/canceled`; `Promote → Demo` nije odobren. Nema demo ili production deploya ni provider aktivacije. 6. 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. 7. 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. 8. 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: 1. G1-02 prvo definira centralni security verdict interface; G1-01 ga obvezno koristi i nema javnog endpointa prije security `PASS`-a. 2. Proširuje se postojeći `inbox_items` document lineage; ne uvodi se četvrti paralelni document model i ne preuzima se scope MC #106632. 3. Storage ugovor ostaje backend-neutralan, uz lokalni sintetički test backend; produkcijski cloud binding zahtijeva zasebnu odluku. 4. Izolirani test koristi stvarni digest-pinned ClamAV; timeout ili greška fail-closed vode u karantenu. 5. Svaki mrežno dostupan upload put koristi isti pre-write gate ili ostaje isključen; zasebna površina dobiva vlastiti praćeni follow-up. 6. 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. 7. Kriterij 95% testnog corpusa računa se tek u agregatnom G1-10 acceptanceu. 8. 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 1. izdavanje računa i eRačun TEST tok; 2. email/PDF/XML/fotografija u document inbox; 3. naplata putem CSV bankovnog izvoda; 4. KPO automatski izveden iz verificiranih naplata; 5. compliance obveze i podsjetnici; 6. jedinstveni exception inbox; 7. 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: 1. Tok, ali samo ako postoji verificirani licencirani/partnerski AIS put, stvarni bank coverage i SLA; 2. drugi licencirani AIS agregator; 3. 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 1. **Shadow (2–4 tjedna):** nema auto-POST/submit; mjeri se točnost. 2. **Assisted (2–4 tjedna):** green DRAFT automatski; čovjek potvrđuje. 3. **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 1. **Unit:** porezne formule, rounding, OIB/IBAN, rule matching, lane odluka. 2. **Property-based:** debit=credit, idempotency, duplicate prevention, monotoni status lifecycle. 3. **Contract:** sveRačun, AIS provider, email, OCR i webhook sheme. 4. **Integration:** PostgreSQL/RLS, object storage, queue, retry/DLQ, scheduler. 5. **Golden accounting dataset:** dokument → očekivani tax/account/posting/exception. 6. **Browser E2E:** stvarni korisnički tokovi, ne samo render stranice. 7. **Operational:** backup/restore, replay, provider outage, alert i incident runbook. 8. **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 1. otvoriti jedan parent epic “Bilko HR Autopilot” s gateovima G0–G6; 2. napraviti capability inventory i uskladiti tri statusna izvora; 3. imenovati hrvatskog računovodstvenog reviewera; 4. potvrditi komercijalnog i tehničkog ownera za sveRačun; 5. provesti AIS/Tok feasibility checkpoint; 6. definirati canonical document i decision-audit shemu; 7. izvući pilot uključne/isključne kriterije i listu kandidata; 8. napisati prvih 25 golden KPO test slučajeva; 9. zatvoriti onboarding/billing i tenant-isolation P0 nalaze; 10. 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.** 1. **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. 2. ~~**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`. 3. **`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) 4. **Zamrznuti peto tržište** dok kapija nije zelena u CI-u 5. **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 { }`**: ```kotlin dbQuery { Organizations.selectAll().where { ... }.singleOrNull() } ``` **`dbQuery` ne otvara transakciju.** `DbDispatcher.kt:48`: ```kotlin 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`: ```kotlin // @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.