Accounted rebrand + swarm-skill cleanup + bank-reconciliation fixes (#643)
* feat(reconciliation): close the bank-feed loop on voucher links and re-tag mis-typed opening balances
Two related fixes to bank reconciliation correctness:
1. Auto-reconcile on voucher link. Linking an invoice or supplier invoice to
an existing voucher previously advanced only the invoice — the bank
transaction that paid it kept sitting in the Transactions inbox with a null
journal_entry_id. linkInvoiceToVoucher / linkSupplierInvoiceToVoucher now
call autoReconcileTransactionForLinkedVoucher (lib/reconciliation), which
links the bank transaction to the same verifikat when exactly one unbooked
line matches it. Best-effort and post-commit: a failure here never fails the
link. The result surfaces reconciledTransactionId; the inbox row leaves the
list and the UI shows link_success_tx_reconciled.
2. Re-tag mis-typed opening balances. getReconciliationStatus and the GL-line
matching RPCs identify a cash account's ingående balans solely by
journal_entries.source_type='opening_balance'. Companies migrated from other
systems often booked the bank IB as an ordinary voucher (source_type
'import' or 'manual'), so it was never excluded and surfaced as a phantom
reconciliation difference equal to the opening balance. Adds:
- migration mark_entry_as_opening_balance: a GUC-gated carve-out in the
immutability trigger plus a SECURITY DEFINER RPC that validates the entry
(balance-sheet lines only, dated on a fiscal-period boundary), flips the
source_type, and writes an audit row — no blanket data sweep.
- POST /api/reconciliation/bank/mark-opening-balance + MarkOpeningBalanceSchema.
- BankReconciliationView action to trigger it from the IB diff.
The gnubok_create_voucher executor now accepts a typed is_opening_balance flag
and derives source_type='opening_balance' only after validating class 1/2 lines
on the period start, so new IBs land correctly typed.
Covered by lib/reconciliation auto-reconcile tests, voucher-executors tests,
and a mark-entry-as-opening-balance pg-real test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* chore: rebrand gnubok → Accounted and prune swarm agent skills
Product rebrand and skills housekeeping. No runtime behaviour change.
Rebrand: replace user-visible "gnubok" with "Accounted" across docs, READMEs,
in-code comments, doc-site content, MCP skill/resource prose, and the
gnubok-mcp package description. The MCP resource URI scheme is moved gnubok://
→ Accounted:// consistently across resource registrations, the event-type
comment, and the resource/skill tests. Deliberately preserved as stable
identifiers (NOT rebranded): the gnubok-company-id cookie, gnubok_sk_ / gnubok_inv_
token prefixes, the gnubok-mcp npm bridge name, and the AGI <gem:Programnamn>
value (kept 'gnubok' per its source comment — it is the software identifier sent
to Skatteverket and must not churn across visual rebrands).
Skills: remove the 27 swarm-* agent SKILL.md atoms (no longer used; already
absent from the agent_atom_registry in prod), refresh the remaining skill docs,
add the .claude/rules/ path-scoped rule set, and regenerate the
seed_agent_atom_bodies migration + .skill-body-manifest.json via
`npm run skills:generate` so the DB-backed skill bodies match the trimmed set.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jakob Wennberg
@@ -0,0 +1,53 @@
|
||||
---
|
||||
paths:
|
||||
- "app/api/**"
|
||||
---
|
||||
|
||||
# API Route Pattern
|
||||
|
||||
Use the `/erp-api-route` skill when scaffolding new endpoints.
|
||||
|
||||
```typescript
|
||||
import { createClient } from '@/lib/supabase/server'
|
||||
import { NextResponse } from 'next/server'
|
||||
import { ensureInitialized } from '@/lib/init'
|
||||
import { validateBody } from '@/lib/api/validate'
|
||||
import { MySchema } from '@/lib/api/schemas'
|
||||
|
||||
ensureInitialized() // Module-level — loads extensions for event emission
|
||||
|
||||
export async function POST(request: Request) {
|
||||
const supabase = await createClient()
|
||||
const { data: { user } } = await supabase.auth.getUser()
|
||||
if (!user) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
|
||||
|
||||
const result = await validateBody(request, MySchema)
|
||||
if (!result.success) return result.response
|
||||
|
||||
// Business logic... always filter by company_id (defense in depth alongside RLS)
|
||||
return NextResponse.json({ data: result })
|
||||
}
|
||||
```
|
||||
|
||||
- Dynamic route params: `{ params }: { params: Promise<{ id: string }> }` (Next.js 16 — params are async).
|
||||
- Response shapes: `{ data }` for success, `{ error }` for failures.
|
||||
- Zod schemas in `lib/api/schemas.ts` — 100+ schemas with shared primitives (uuid, isoDate, accountNumber, nonNegativeAmount).
|
||||
- Routes that emit events must call `ensureInitialized()` at module level.
|
||||
- API-key auth uses `createServiceClientNoCookies()`; every query still filters by `company_id`.
|
||||
|
||||
## Endpoint map (`app/api/`)
|
||||
|
||||
- `/api/bookkeeping/*` — accounts, fiscal periods, journal entries (CRUD/reverse/correct), mapping rules, voucher gaps
|
||||
- `/api/invoices/*`, `/api/supplier-invoices/*` — CRUD + state transitions
|
||||
- `/api/transactions/*` — categorize, describe, book, match-{invoice,supplier-invoice}, batch, AI suggestions
|
||||
- `/api/customers/*`, `/api/suppliers/*` — CRUD
|
||||
- `/api/documents/*` — CRUD, versions, link, match-sweep, verify cron
|
||||
- `/api/reports/*` — report endpoints (GL, TB, BS, IS, AR/supplier ledger, VAT, SIE, INK2, NE-bilaga, KPI, audit, continuity, monthly, full-archive, salary, vacation, avgifter)
|
||||
- `/api/salary/*` — employees, payroll-config, tax-tables, KU, runs
|
||||
- `/api/import/*` — bank-file, SIE (parse/execute/mappings)
|
||||
- `/api/reconciliation/bank/*`, `/api/settings/*`, `/api/company/*`, `/api/team/*`
|
||||
- `/api/deadlines/*`, `/api/tax-deadlines/*` — CRUD + crons
|
||||
- `/api/pending-operations/*`, `/api/events/*`, `/api/audit-trail/*`
|
||||
- `/api/calendar/feed/[token]`, `/api/mcp-oauth/*`, `/api/support/contact`, `/api/account/delete`
|
||||
- `/api/log`, `/api/health`, `/api/vat/validate`, `/api/currency/rate`, `/api/sandbox/*`
|
||||
- `/api/extensions/ext/[...path]` — dynamic extension routes (catch-all → `/api/extensions/ext/{extensionId}/{routePath}`, path params as `_paramName` query)
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
paths:
|
||||
- "lib/bookkeeping/**"
|
||||
- "lib/core/**"
|
||||
- "lib/reports/**"
|
||||
- "lib/vat/**"
|
||||
- "lib/invoices/**"
|
||||
- "lib/salary/**"
|
||||
---
|
||||
|
||||
# Bookkeeping Domain Reference
|
||||
|
||||
For Swedish accounting-law questions, use the domain skills (`swedish-vat`, `swedish-accounting-compliance`, `swedish-year-end-closing`, etc.). The accounting guard rails in the root `CLAUDE.md` always apply.
|
||||
|
||||
## Core Services (`lib/core/`)
|
||||
|
||||
- `bookkeeping/period-service.ts` — Fiscal period lifecycle management (open, close, lock)
|
||||
- `bookkeeping/year-end-service.ts` — Year-end closing procedures
|
||||
- `bookkeeping/storno-service.ts` — Reversal/correction entry generation
|
||||
- `tax/tax-code-service.ts` — Tax code definitions and rates
|
||||
- `audit/audit-service.ts` — Audit trail and compliance logging
|
||||
- `documents/document-service.ts` — Document attachment lifecycle (WORM storage with version chains)
|
||||
|
||||
## Key BAS Accounts
|
||||
|
||||
`1510` Accounts receivable | `1930` Business bank account | `2013` Private withdrawals (EF) | `2440` Accounts payable | `2611`/`2621`/`2631` Output VAT 25%/12%/6% | `2641` Input VAT | `2645` Calculated input VAT (EU) | `2893` Shareholder loan (AB) | `3001`/`3002`/`3003` Revenue 25%/12%/6% | `3305`/`3308` Export/EU service revenue
|
||||
|
||||
BAS data (`lib/bookkeeping/bas-data/`): full BAS 2026 chart by class (1–8) + SRU mapping. Account numbers are **strings** (`'1930'`, never `1930`).
|
||||
|
||||
## VAT Treatments
|
||||
|
||||
`standard_25`, `reduced_12`, `reduced_6`, `reverse_charge`, `export`, `exempt`
|
||||
|
||||
Invoice items support individual `vat_rate` values (mixed-rate invoices). Use `getAvailableVatRates(customerType, vatNumberValidated)` from `lib/invoices/vat-rules.ts`. VIES validation via `lib/vat/vies-client.ts`.
|
||||
|
||||
## VAT Declaration Rutor (SKV 4700)
|
||||
|
||||
`VatDeclarationRutor` type maps to momsdeklaration:
|
||||
- **Ruta 05**: Domestic taxable sales (3001+3002+3003)
|
||||
- **Ruta 06/07**: Unused, always 0
|
||||
- **Ruta 10/11/12**: Output VAT 25%/12%/6% (2611/2621/2631)
|
||||
- **Ruta 39/40**: EU services / Export (3308/3305)
|
||||
- **Ruta 48**: Input VAT (2641/2645)
|
||||
- **Ruta 49**: Moms att betala/återfå = (10+11+12+30+31+32+60+61+62) − 48
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
paths:
|
||||
- "supabase/migrations/**"
|
||||
- "tests/pg/**"
|
||||
---
|
||||
|
||||
# Database & Migrations
|
||||
|
||||
Use the `/supabase-migration` skill for new migrations.
|
||||
|
||||
**Location**: `supabase/migrations/` — 330+ files. Early migrations use sequential numbering (`20240101000001`–`20240101000038`), later ones use real timestamps.
|
||||
|
||||
## Migration Rules
|
||||
|
||||
1. Enable RLS + policies using `user_company_ids()` for company-scoped data
|
||||
2. Add `updated_at` trigger via `update_updated_at_column()`
|
||||
3. UUID PKs: `DEFAULT uuid_generate_v4()`
|
||||
4. Company ownership: `company_id UUID REFERENCES companies NOT NULL` + `user_id UUID REFERENCES auth.users ON DELETE CASCADE NOT NULL`
|
||||
5. Never modify existing migrations — create new ones
|
||||
6. Never modify enforcement triggers (migration 017) — legally required
|
||||
7. Apply via Supabase MCP `apply_migration`
|
||||
8. Always end with `NOTIFY pgrst, 'reload schema'` when altering table structure
|
||||
|
||||
**pg-real tests**: any PR touching a trigger/RPC/RLS/DEFERRABLE must include or extend a `*.pg.test.ts`. Parallel Vitest project against real Postgres (CI: `supabase/postgres:15`, migrations replayed). Local: `npm run test:pg`. Helpers: `tests/pg/setup.ts` (`getPool()`, `withUserContext()`), `tests/pg/fixtures.ts` (`seedCompany()`, `insertDraftJournalEntry()`, etc.).
|
||||
|
||||
## Key Tables (~60)
|
||||
|
||||
- **Multi-tenant**: `companies`, `company_members`, `company_invitations`, `teams`, `team_members`, `team_invitations`, `user_preferences`, `profiles`
|
||||
- **Bookkeeping**: `chart_of_accounts`, `fiscal_periods`, `journal_entries`, `journal_entry_lines`, `account_balances`, `voucher_sequences`, `voucher_gap_explanations`
|
||||
- **Invoicing**: `customers`, `invoices`, `invoice_items`, `invoice_payments`, `invoice_inbox_items`
|
||||
- **Suppliers**: `suppliers`, `supplier_invoices`, `supplier_invoice_items`
|
||||
- **Banking**: `bank_connections`, `transactions`, `bank_file_imports`, `payment_match_log`
|
||||
- **Documents**: `document_attachments` (WORM), `receipts`, `receipt_line_items`
|
||||
- **Settings**: `company_settings`, `mapping_rules`, `categorization_templates`, `booking_template_library`, `extension_data`
|
||||
- **Dimensions**: `cost_centers`, `projects`
|
||||
- **Tax/Deadlines**: `tax_rates`, `tax_table_rates`, `deadlines`, `calendar_feeds`, `skatteverket_tokens`
|
||||
- **API/Auth**: `api_keys`, `oauth_used_codes`, `bankid_identities`
|
||||
- **Audit/Ops**: `audit_log` (immutable), `event_log` (30d TTL), `pending_operations`, `processing_history`, `ai_usage_tracking`, `automation_webhooks`
|
||||
- **Inbox**: `invoice_inbox_items`, `company_inboxes`, `email_connections`
|
||||
- **Salary**: `employees`, `salary_runs`, `salary_run_employees`, `salary_line_items`, `salary_payroll_config`, `agi_declarations`
|
||||
- **Providers**: `provider_consents`, `provider_consent_tokens`, `provider_otc`
|
||||
- **Agent**: `agent_atom_registry` (inlined skill bodies — see below)
|
||||
- **Other**: `sandbox_users`
|
||||
|
||||
## Key RPC Functions
|
||||
|
||||
- `create_company_with_owner()` — Atomic company + owner creation
|
||||
- `commit_journal_entry()` — Atomic draft→posted with voucher number
|
||||
- `next_voucher_number()` — Concurrent-safe voucher generation
|
||||
- `detect_voucher_gaps()` — BFNAR 2013:2 gap detection
|
||||
- `generate_invoice_number()`, `get_next_arrival_number()`, `generate_delivery_note_number()` — Sequence generators
|
||||
- `seed_chart_of_accounts()` — BAS chart seeding per entity type
|
||||
- `validate_and_increment_api_key()` — Atomic rate limiting
|
||||
- `user_company_ids()` — RLS helper returning user's company IDs
|
||||
- `get_unlinked_1930_lines()` — Bank reconciliation helper
|
||||
- `cleanup_sandbox_user()`, `cleanup_expired_sandbox_users()` — Sandbox lifecycle
|
||||
|
||||
## Key Triggers
|
||||
|
||||
- `check_journal_entry_balance()` — Debit must equal credit
|
||||
- `enforce_journal_entry_immutability()` — Posted entries cannot be modified
|
||||
- `enforce_period_lock()` — No entries in closed/locked periods
|
||||
- `enforce_company_lock_date()` — Company-wide bookkeeping lock date
|
||||
- `block_document_deletion()` — WORM compliance
|
||||
- `enforce_retention_journal_entries()` — 7-year retention
|
||||
- `audit_log_immutable()` — Audit log cannot be modified
|
||||
- `write_audit_log()` — Auto-audit on DML operations
|
||||
- `sync_team_member_to_companies()` — Auto-sync team→company membership
|
||||
|
||||
## Agent skill bodies (`agent_atom_registry`)
|
||||
|
||||
Skill content is authored in `.claude/skills/**/SKILL.md` and inlined into the DB `body` column at runtime (not read from disk — that doesn't bundle on Vercel/Docker). After editing any atom SKILL.md, run `npm run skills:generate` to emit a new `*_seed_agent_atom_bodies.sql` migration and commit it; `npm run skills:check` (wired into CI) fails the build if you forget. Only the curated tiers become atoms — `swedish-*` (horizontal), `industry/<slug>` (vertical), `modifier/<slug>` (modifier); other Claude Code skills never become atoms. The MCP server exposes only atoms with `mcp_exposed = true`.
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
paths:
|
||||
- "app/**"
|
||||
- "components/**"
|
||||
---
|
||||
|
||||
# Design Context & Design System
|
||||
|
||||
Always use the `/frontend-design` skill for new UI. The conventions below are locked — deviating from them on existing pages is a regression.
|
||||
|
||||
## Users
|
||||
|
||||
Swedish sole traders (enskild firma) and small business owners (aktiebolag) who manage their own bookkeeping. They are not accountants — they are professionals (consultants, freelancers, shop owners) who want to stay compliant without hiring one. They use Accounted in short, focused sessions: sending an invoice, categorizing bank transactions, filing a VAT declaration. Speed and clarity matter.
|
||||
|
||||
## Brand & Aesthetic
|
||||
|
||||
**Editorial monochrome.** Paper-white surfaces, hairline borders, serif headlines. The interface should feel like a well-made instrument — considered, quiet, confident. Anti-references: enterprise software (SAP/Oracle density), neon SaaS coldness.
|
||||
|
||||
- **Palette**: Achromatic foundation. Pure white background, warm beige (`40 11% 89%`) for chips / active sidebar / hover / secondary buttons. Achromatic primary (no cool tint). Semantic colors (`--success` sage, `--warning` ochre, `--destructive` terracotta) exist but are **data-only** — they appear in charts and financial numbers (positive/negative deltas), never as chrome backgrounds. In chrome, only `--destructive` survives.
|
||||
- **Typography**: Hedvig Letters Serif for display headings, Geist (sans) for body, forms, and tables. Hedvig is single-weight (400) — do not apply `font-medium` to display text; its natural high-contrast strokes carry the weight. Tabular numbers everywhere financial data appears.
|
||||
- **Surfaces**: Cards sit flat on the page — no shadow, full-opacity hairline border (`border-border`), `rounded-lg` (8px). Card background matches page background; the border carries hierarchy. Dark mode drops the warm tint from secondary for a pure-gray mood shift; light mode keeps the beige.
|
||||
- **Spacing**: Generous whitespace. Dense data (tables, ledgers) uses tighter spacing but never feels cramped.
|
||||
- **Motion**: Functional, not decorative. No press-scale, no hover-lift, no spring overshoot. Hover state is a flat background shift (`bg-secondary/60`). `transition-colors duration-150` is the default. Stagger animations on list entry are fine. Respect `prefers-reduced-motion` (already wired).
|
||||
- **Icons**: Lucide — 15px in navigation, slightly larger in empty states.
|
||||
|
||||
## Design Principles
|
||||
|
||||
1. Clarity over cleverness — Swedish labels, obvious hierarchy.
|
||||
2. Earned minimalism — remove what doesn't serve the task, keep compliance context.
|
||||
3. Numbers are first-class — tabular-nums, alignment, positive/negative clarity.
|
||||
4. Trust through consistency.
|
||||
5. Speed is a feature — optimize for the 90-second session.
|
||||
|
||||
## Accessibility
|
||||
|
||||
WCAG AA (4.5:1 text, 3:1 UI). Keyboard-navigable + visible focus rings. Respect `prefers-reduced-motion`. Color never sole state indicator. Touch targets ≥40px (44px for mobile-critical). Icon-only buttons need `aria-label`.
|
||||
|
||||
## Design System Tokens
|
||||
|
||||
**Spacing scale.** Only use Tailwind values `1, 2, 3, 4, 6, 8, 10, 12`. **Forbidden:** `2.5`, `5`, hardcoded pixels in page logic.
|
||||
|
||||
| Token | Tailwind | Use for |
|
||||
|---|---|---|
|
||||
| 4 | `1` | icon padding |
|
||||
| 8 | `2` | tight inline gaps |
|
||||
| 12 | `3` | dense list rows, badge gaps |
|
||||
| 16 | `4` | default form / control / grid gap |
|
||||
| 24 | `6` | **card padding default** (`p-6`) |
|
||||
| 32 | `8` | **between page sections** (`space-y-8` on page root) |
|
||||
| 40 | `10` | hero spacing |
|
||||
| 48 | `12` | top of page after header |
|
||||
|
||||
Compact metric cards (e.g. dashboard tiles, salary KPI row) use `p-4`. Detail cards use `p-6`. Never mix `p-5`.
|
||||
|
||||
**Layout.**
|
||||
- Sidebar width: `md:w-64` (256px). Main content offset: `md:pl-64`.
|
||||
- Main container: `max-w-5xl mx-auto px-5 py-8 md:px-8 md:py-10` (via `components/dashboard/MainContainer.tsx`).
|
||||
- Page root: `<div className="space-y-8">`.
|
||||
|
||||
**Primitives — always use these, don't hand-roll.**
|
||||
|
||||
| Need | Component | Notes |
|
||||
|---|---|---|
|
||||
| Page title + action | `components/ui/page-header.tsx` `PageHeader` | Use this, not bespoke `<h1>` + `<p>` blocks. Drop the `description` prop when it just paraphrases the title. |
|
||||
| Data table | `components/ui/table.tsx` `Table / TableHeader / TableHead / TableRow / TableCell` | Header style is baked in: `text-[11px] font-medium uppercase tracking-wider text-muted-foreground`. Wrap in `<CardContent className="p-0">` when the table is a card's primary content. Add `tabular-nums` to numeric cells. |
|
||||
| Status indicator | `components/ui/badge.tsx` `<Badge variant>` | Variants: `default / secondary / success / warning / destructive / outline`. **Never** use raw Tailwind colors (`bg-blue-100`, `bg-emerald-500/10`, etc.) for status. Map status → variant via a small `Record` per feature. |
|
||||
| No-data state | `components/ui/empty-state.tsx` `EmptyState` | Don't hand-roll `<div className="flex flex-col items-center py-12">…</div>`. Preset variants exist (`EmptyInvoices`, `EmptyCustomers`, `EmptyTransactions`, etc.). |
|
||||
| Loading placeholder | `components/ui/skeleton.tsx` `<Skeleton>` | Don't hand-roll `bg-muted rounded animate-pulse` divs. |
|
||||
| Inline help / formulas | `components/ui/info-tooltip.tsx` `InfoTooltip` | Hover-revealed; don't use always-visible info buttons. |
|
||||
| Fiscal year picker | `components/common/FiscalYearSelector.tsx` | Don't use raw `<select>` for fiscal periods. |
|
||||
|
||||
**Tabular display rules.**
|
||||
- All financial values get `tabular-nums`.
|
||||
- Dates in tables: `tabular-nums` for fixed width.
|
||||
- Right-align numeric columns (`text-right`).
|
||||
- For group bands inside tables (Resultatrapport-style): `<tr className="bg-muted/30"><td colSpan={n} className="px-4 py-2 text-[12px] font-semibold text-muted-foreground">{label}</td></tr>`.
|
||||
|
||||
**Date formatting.** Two helpers in `lib/utils.ts`:
|
||||
- `formatDate(x)` → `2026-05-11` (ISO `yyyy-MM-dd`). Use for accounting data — transaction dates, invoice dates, payment dates, voucher dates. Aligns in tables, matches SIE/BFL convention.
|
||||
- `formatDateLong(x)` → `11 maj 2026` (Swedish long form). Use for metadata — when something was created, linked, verified, expires. Settings panels and audit displays.
|
||||
|
||||
Never render raw `{x.invoice_date}` directly — always route through `formatDate()` for code consistency.
|
||||
|
||||
**Currency.** `formatCurrency(n, currency?)` from `lib/utils.ts`. Default SEK.
|
||||
|
||||
**Typography.**
|
||||
- Page title: use `PageHeader` (renders `font-display text-3xl md:text-4xl tracking-tight`). Do not hand-roll an `<h1>`.
|
||||
- Card title: `<CardTitle className="text-base">` for sections, default for primary cards. The primitive already drops `font-medium` — do not add it back.
|
||||
- Section divider header inside a page: `<h2 className="text-sm font-medium uppercase tracking-wider text-muted-foreground">`.
|
||||
- Headline number: `font-display text-xl tabular-nums`. No `font-medium` — Hedvig's natural weight carries the gravitas.
|
||||
- Display font (`font-display`, Hedvig Letters Serif) reserved for h1/h2/h3 and primary financial numbers. If a specific `font-display` numeral reads weak inside a compact metric card, override that call site with `font-sans tabular-nums` (Geist) — better legibility on small numerals.
|
||||
|
||||
**Forbidden / dead patterns.**
|
||||
- Page descriptions that paraphrase the page title (e.g. `<PageHeader title="Fakturor" description="Hantera dina fakturor">`) → drop the description.
|
||||
- Two different status indicators on the same element (e.g. colored card border *and* Badge for status) → pick one (prefer Badge).
|
||||
- Mobile-specific `<select>` duplicating desktop tabs in code — use a single Tabs primitive or a single grouped `Select`.
|
||||
- Hand-rolled icon buttons smaller than `h-10 w-10`. Use shadcn `Button size="icon"`.
|
||||
- Color-coded status using full-rainbow Tailwind palette (`bg-amber-100`, `bg-emerald-500/10`, etc.). Use Badge variants tied to the brand palette.
|
||||
- `shadow-sm` / `shadow-md` / `shadow-lg` on cards, buttons, or list items. The aesthetic is flat-with-hairlines — surfaces use `border-border`, not elevation. Shadows survive only on dialogs/popovers/dropdowns (anything that overlays the page).
|
||||
- `active:scale-[...]` on buttons. Buttons do not bounce.
|
||||
- `bg-gradient-to-*` on page or card backgrounds. Flat surfaces only.
|
||||
- `font-medium` on display elements (`font-display`, h1/h2/h3, CardTitle, PageHeader title). Hedvig is single-weight by design.
|
||||
- `rounded-xl` (12px) on cards. Cards are `rounded-lg` (8px). `rounded-xl` survives only on prominent hero-style surfaces if absolutely needed.
|
||||
- Opacity-suffixed border classes (`border-border/30`, `border-border/60`) on cards and primary surfaces. Use full-opacity `border-border` — the new border token is calibrated for that.
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
paths:
|
||||
- "app/**"
|
||||
- "components/**"
|
||||
- "messages/**"
|
||||
- "lib/email/**"
|
||||
- "lib/invoices/**"
|
||||
- "lib/reports/**"
|
||||
- "lib/salary/**"
|
||||
---
|
||||
|
||||
# i18n
|
||||
|
||||
The app is Swedish-first and bilingual (Swedish + English) for UI chrome. Locale is per-user on `user_preferences.locale` (`'sv' | 'en'`, default `'sv'`), resolved server-side via next-intl. The user picker lives at `/settings/account`.
|
||||
|
||||
**Pattern for new UI:**
|
||||
|
||||
```tsx
|
||||
// Server component
|
||||
import { getTranslations } from 'next-intl/server'
|
||||
const t = await getTranslations('namespace')
|
||||
|
||||
// Client component
|
||||
'use client'
|
||||
import { useTranslations } from 'next-intl'
|
||||
const t = useTranslations('namespace')
|
||||
|
||||
// In JSX
|
||||
<button>{t('save')}</button>
|
||||
```
|
||||
|
||||
Add new strings to both `messages/sv.json` and `messages/en.json` under the matching namespace (`common`, `nav`, `auth`, `settings`, `empty`, etc.). Never ship an English key without a Swedish counterpart — Swedish is the default and the fallback.
|
||||
|
||||
**Locale-aware formatters:**
|
||||
- `formatCurrency(amount)` — stays SEK with sv-SE conventions in BOTH locales (Swedish accounting standard, not a UI string).
|
||||
- `formatDate(date)` — ISO `yyyy-MM-dd`, locale-independent.
|
||||
- `formatDateLong(date, locale)` — accepts locale. In client components use `useFormat()` (`lib/hooks/use-format.ts`) which pulls the active locale.
|
||||
|
||||
**Error messages:** `getErrorMessage(err, { locale, context })` from `lib/errors/get-error-message.ts` is bilingual on the primary maps (Postgres codes, HTTP statuses, context fallbacks, generic fallback). The structured error envelope (`{ error: { code, message, message_en } }`) already carries both; the function picks the right one from `locale`. Pass `useLocale()` / `getLocale()` as the locale arg.
|
||||
|
||||
**Stays Swedish — do NOT translate:**
|
||||
|
||||
| Surface | Reason |
|
||||
|---|---|
|
||||
| Invoice PDFs (`lib/invoices/pdf-template.tsx`) | Customer-facing — driven by `customer.language` (`sv` default, `en` opt-in). The template's chrome translates; statutory chapter refs (ML 17 kap 24§, ML 3 kap.) stay intact in both locales. |
|
||||
| Customer email templates (`lib/email/invoice-templates.ts`, `reminder-templates.ts`) | Same — `customer.language` drives the output. `reminder-templates.ts` is still Swedish-only; mirror the PDF/invoice-templates approach if you add English here. |
|
||||
| Year-end wizard (`app/(dashboard)/bookkeeping/year-end/page.tsx`) | Statutory bokslut terminology; English would be misleading |
|
||||
| Journal entry editor (`app/(dashboard)/bookkeeping/[id]/page.tsx`) | Deeply regulatory (verifikat, voucher numbers, BAS) |
|
||||
| INK2 / NE-bilaga / SRU (`lib/reports/ink2/**`, `lib/reports/ne-bilaga/**`, `lib/reports/sru-*`) | Skatteverket forms — field codes and labels are statutory |
|
||||
| SIE export (`lib/reports/sie-export.ts`) | SIE format is Swedish-only by spec (#KONTO, #VER, etc.) |
|
||||
| BAS chart names (`lib/bookkeeping/bas-data/**`) | Standardized Swedish account names per BAS 2026 |
|
||||
| VAT declaration ruta labels (`lib/reports/vat-declaration*.ts`) | Momsdeklaration field labels are Skatteverket form labels |
|
||||
| Salary AGI / KU (`lib/salary/agi*`, `lib/salary/ku*`) | Skatteverket-bound forms |
|
||||
| Bookkeeping engine domain errors ("Verifikationen balanserar inte", "Bokföringen är låst") | Regulatory concepts; English equivalents would be ambiguous |
|
||||
|
||||
Anything in the table above stays Swedish in BOTH locales. If you find yourself reaching for `t()` inside one of these files, stop and reconsider.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
paths:
|
||||
- "extensions/general/mcp-server/**"
|
||||
- "packages/gnubok-mcp/**"
|
||||
---
|
||||
|
||||
# MCP Server
|
||||
|
||||
Accounted exposes its bookkeeping engine as an MCP server for Claude Desktop/Code.
|
||||
|
||||
**MCP extension** (`extensions/general/mcp-server/`): 90+ tools covering transactions, categorization, customers/suppliers, invoices, accounts, fiscal periods, reports (trial balance, GL, BS, IS, AR/supplier ledger, VAT, KPI), reconciliation, salary runs, AGI, year-end, document upload, and loadable skills. JSON-RPC 2.0. Endpoint: `/api/extensions/ext/mcp-server/mcp`.
|
||||
|
||||
**OAuth 2.1** for Claude connectors: `.well-known/oauth-protected-resource` + `.well-known/oauth-authorization-server` discovery; `/api/mcp-oauth/authorize`, `/token` (PKCE), `/register`. Stateless AES-256-GCM auth codes (`lib/auth/oauth-codes.ts`). Single-use via `oauth_used_codes`. Allowlist: `claude.ai/api/*`, `claude.com/api/*`, `localhost`.
|
||||
|
||||
**npm package** (`packages/gnubok-mcp`): Stdio-to-HTTP bridge; users run `npx gnubok-mcp` with API key.
|
||||
|
||||
## Tool authoring conventions (enforced by tests)
|
||||
|
||||
- Every `inputSchema` must declare `additionalProperties: false` at the top level. Guarded by `extensions/general/mcp-server/__tests__/strict-schemas.test.ts`.
|
||||
- Tool descriptions must be ≤ 280 chars (guarded by `output-schema.test.ts`). No `Args:` / `Returns:` / `Examples:` blocks — those belong in JSON Schema, not description prose. Use agent-native hints like "Use to…" / "Call X first" instead.
|
||||
- Completion-signal pattern: tools that stage operations return `STAGED_OPERATION_SCHEMA` — `{ staged, risk_level, actor, message, preview, period_status?, next? }`. The `staged: true` boolean is the explicit completion signal; agents must not infer completion from prose. Do NOT introduce a parallel `{ success, shouldContinue, output }` envelope.
|
||||
- Tools that touch a fiscal-period-bound date (categorize, mark paid, create voucher, correct/reverse entry, approve supplier invoice) pass `dateForPeriodCheck` to `stagePendingOperation` so the response includes `period_status: { period_id, status: open|locked|closed, lock_date }`. Widgets and agents use this to disable writes without round-trips.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: create-extension
|
||||
description: "Generate and implement extensions for gnubok: scaffold files, configure manifests, write event handlers, API routes, services, workspace UIs, settings panels, and testing. Use when creating new extensions, adding surfaces to existing extensions, or understanding the extension architecture. Covers the full lifecycle from scaffolding to registration."
|
||||
description: "Generate and implement extensions for Accounted: scaffold files, configure manifests, write event handlers, API routes, services, workspace UIs, settings panels, and testing. Use when creating new extensions, adding surfaces to existing extensions, or understanding the extension architecture. Covers the full lifecycle from scaffolding to registration."
|
||||
---
|
||||
|
||||
# Extension Generator
|
||||
|
||||
@@ -59,5 +59,4 @@ const isAvailable = ENABLED_EXTENSION_IDS.has('my-extension')
|
||||
|
||||
```typescript
|
||||
const { data, save, remove, getByKey } = useExtensionData('general', 'my-extension')
|
||||
const { totals, monthly, totalNet } = useAccountTotals({ from, to, monthly: true })
|
||||
```
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
## Perspective
|
||||
|
||||
You are scanning for Swedish accounting compliance issues, bookkeeping logic gaps, and financial data handling problems. gnubok implements double-entry bookkeeping compliant with Bokforingslagen (BFL) and BFN standards. Focus on correctness of journal entries, VAT handling, account mappings, and legal guardrails.
|
||||
You are scanning for Swedish accounting compliance issues, bookkeeping logic gaps, and financial data handling problems. Accounted implements double-entry bookkeeping compliant with Bokforingslagen (BFL) and BFN standards. Focus on correctness of journal entries, VAT handling, account mappings, and legal guardrails.
|
||||
|
||||
## Checklist
|
||||
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
## Perspective
|
||||
|
||||
You are scanning for design and UX issues in the gnubok interface. The app follows a minimal, sharp, efficient aesthetic inspired by Mercury (banking). Evaluate against the gnubok design system: grayscale palette with sage green/terracotta/ochre accents, Fraunces headings, Geist body, generous whitespace, subtle motion.
|
||||
You are scanning for design and UX issues in the Accounted interface. The app follows an editorial-monochrome aesthetic — paper-white surfaces, hairline borders, serif headlines; considered and quiet. Evaluate against the Accounted design system: achromatic palette (semantic sage/ochre/terracotta are data-only — charts and financial deltas, never chrome), Hedvig Letters Serif display headings, Geist body, generous whitespace, functional (non-decorative) motion.
|
||||
|
||||
## Checklist
|
||||
|
||||
### Consistency & Design System
|
||||
- [ ] Spacing values use Tailwind scale (not arbitrary values)
|
||||
- [ ] Colors are from the design palette (grayscale, sage green, terracotta, ochre)
|
||||
- [ ] Fraunces used for display headings, Geist for body text
|
||||
- [ ] Hedvig Letters Serif used for display headings, Geist for body text
|
||||
- [ ] `tabular-nums` applied to all financial/numeric data
|
||||
- [ ] shadcn/ui components used where appropriate
|
||||
- [ ] Icon sizes consistent (15px nav, larger for empty states)
|
||||
- [ ] Border styles consistent (subtle, 60% opacity)
|
||||
- [ ] Borders are full-opacity `border-border` on cards/surfaces (no `border-border/60`)
|
||||
|
||||
### Loading & Empty States
|
||||
- [ ] Pages have loading states (skeletons preferred over spinners)
|
||||
@@ -28,7 +28,7 @@ You are scanning for design and UX issues in the gnubok interface. The app follo
|
||||
### Animation & Motion
|
||||
- [ ] List items stagger-animate on entry
|
||||
- [ ] Interactive elements have hover/active transitions
|
||||
- [ ] Transitions use appropriate easing (spring for feedback, ease for reveals)
|
||||
- [ ] Transitions use the project default (`transition-colors duration-150`) — no spring/overshoot
|
||||
- [ ] `prefers-reduced-motion` respected
|
||||
- [ ] No abrupt state changes that need transitions
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: erp-api-route
|
||||
description: "Generate Next.js 16 API routes for gnubok with correct auth guards, Supabase client usage, event emission, journal entry creation, and error handling. Use when creating new API endpoints in app/api/. Handles the Next.js 16 async params pattern, ensureInitialized() for events, non-blocking journal entry wrapping, and defense-in-depth user_id filtering."
|
||||
description: "Generate Next.js 16 API routes for Accounted with correct auth guards, Supabase client usage, event emission, journal entry creation, and error handling. Use when creating new API endpoints in app/api/. Handles the Next.js 16 async params pattern, ensureInitialized() for events, non-blocking journal entry wrapping, and defense-in-depth user_id filtering."
|
||||
---
|
||||
|
||||
# ERP API Route Generator
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
name: mcp-builder
|
||||
description: Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
|
||||
license: Complete terms in LICENSE.txt
|
||||
---
|
||||
|
||||
# MCP Server Development Guide
|
||||
|
||||
@@ -23,7 +23,7 @@ version: 1
|
||||
## When this applies
|
||||
|
||||
The active company is an aktiebolag where one natural person owns > 50% of
|
||||
the shares. This is the most common form among Gnubok's AB users. The owner
|
||||
the shares. This is the most common form among Accounted's AB users. The owner
|
||||
is typically also a full-time anställd in the company and "verksam i betydande
|
||||
omfattning" — which triggers 3:12-reglerna (53 kap. IL).
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: scout-design
|
||||
description: "Scan a specific area of the app for design issues and improvement opportunities, then create Linear tickets for approved findings. Usage: /scout-design <area> (e.g., /scout-design settings, /scout-design bookkeeping). Evaluates against the gnubok design system for consistency, missing states, animation gaps, accessibility, and visual polish."
|
||||
description: "Scan a specific area of the app for design issues and improvement opportunities, then create Linear tickets for approved findings. Usage: /scout-design <area> (e.g., /scout-design settings, /scout-design bookkeeping). Evaluates against the Accounted design system for consistency, missing states, animation gaps, accessibility, and visual polish."
|
||||
---
|
||||
|
||||
# Scout Design
|
||||
@@ -31,11 +31,11 @@ Read ALL files in the resolved scope (pages + components). For each file, evalua
|
||||
**Consistency & Design System**
|
||||
- Are spacing values consistent (using Tailwind scale, not arbitrary values)?
|
||||
- Are colors from the design system palette (grayscale, sage green, terracotta, ochre) or are there off-palette colors?
|
||||
- Are font sizes/weights consistent with the typography system (Fraunces for headings, Geist for body)?
|
||||
- Are font sizes/weights consistent with the typography system (Hedvig Letters Serif for display headings, Geist for body)?
|
||||
- Are `tabular-nums` applied to all financial/numeric data?
|
||||
- Are shadcn/ui components used where appropriate, or are there custom implementations that should use shadcn?
|
||||
- Are icon sizes consistent (15px nav, larger for empty states)?
|
||||
- Are border styles consistent (subtle, 60% opacity)?
|
||||
- Are borders full-opacity `border-border` on cards/surfaces (no opacity-suffixed border classes like `border-border/60`)?
|
||||
|
||||
**Loading & Empty States**
|
||||
- Does the page/component have a loading state? (skeleton, spinner, or shimmer)
|
||||
@@ -50,7 +50,7 @@ Read ALL files in the resolved scope (pages + components). For each file, evalua
|
||||
**Animation & Motion**
|
||||
- Are list items stagger-animated on entry?
|
||||
- Do interactive elements have hover/active transitions?
|
||||
- Are transitions using appropriate easing (spring for feedback, ease for reveals)?
|
||||
- Are transitions using the project default (`transition-colors duration-150`) without spring/overshoot?
|
||||
- Is `prefers-reduced-motion` respected?
|
||||
- Are there abrupt state changes that would benefit from a transition?
|
||||
|
||||
|
||||
@@ -1,22 +1,23 @@
|
||||
---
|
||||
name: supabase-migration
|
||||
description: "Generate Supabase database migrations for the gnubok project with correct RLS policies, triggers, indexes, and Swedish accounting constraints. Use when creating new tables, adding columns, modifying constraints (e.g. source_type CHECK), or any DDL operation on the Supabase database. Ensures legal compliance with BFL 7-year retention, immutability triggers, and period lock enforcement."
|
||||
description: "Generate Supabase database migrations for the Accounted project with correct RLS policies, triggers, indexes, and Swedish accounting constraints. Use when creating new tables, adding columns, modifying constraints (e.g. source_type CHECK), or any DDL operation on the Supabase database. Ensures legal compliance with BFL 7-year retention, immutability triggers, and period lock enforcement."
|
||||
---
|
||||
|
||||
# Supabase Migration Generator
|
||||
|
||||
## Migration Numbering
|
||||
|
||||
Series: `20240101000001` through `20240101000028`. Next: `20240101000029`. Increment from there.
|
||||
Early migrations used the sequential series `20240101000001`–`20240101000038`; the project has long since moved to real timestamps. **New migrations use a current UTC timestamp** `YYYYMMDDHHMMSS_description.sql` (e.g. `20260603120000_add_x.sql`). Never reuse or back-date a number.
|
||||
|
||||
## New Table — Complete Template
|
||||
|
||||
Every new table requires ALL five parts. Missing any is a bug.
|
||||
Accounted is multi-tenant: company-scoped business data is owned by `company_id` and secured with the `user_company_ids()` RLS helper (NOT `auth.uid() = user_id`). Every new company-scoped table requires ALL of these. Missing any is a bug.
|
||||
|
||||
```sql
|
||||
-- 1. Table with UUID PK + user_id FK
|
||||
-- 1. Table with UUID PK + company_id + user_id FKs
|
||||
CREATE TABLE public.tablename (
|
||||
id uuid DEFAULT gen_random_uuid() PRIMARY KEY,
|
||||
company_id uuid NOT NULL REFERENCES public.companies(id) ON DELETE CASCADE,
|
||||
user_id uuid NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
|
||||
-- domain columns --
|
||||
created_at timestamptz NOT NULL DEFAULT now(),
|
||||
@@ -26,18 +27,18 @@ CREATE TABLE public.tablename (
|
||||
-- 2. RLS
|
||||
ALTER TABLE public.tablename ENABLE ROW LEVEL SECURITY;
|
||||
|
||||
-- 3. All four CRUD policies
|
||||
CREATE POLICY "Users can view own tablename"
|
||||
ON public.tablename FOR SELECT USING (auth.uid() = user_id);
|
||||
CREATE POLICY "Users can insert own tablename"
|
||||
ON public.tablename FOR INSERT WITH CHECK (auth.uid() = user_id);
|
||||
CREATE POLICY "Users can update own tablename"
|
||||
ON public.tablename FOR UPDATE USING (auth.uid() = user_id);
|
||||
CREATE POLICY "Users can delete own tablename"
|
||||
ON public.tablename FOR DELETE USING (auth.uid() = user_id);
|
||||
-- 3. All four CRUD policies — scope to the user's companies
|
||||
CREATE POLICY "view own-company tablename"
|
||||
ON public.tablename FOR SELECT USING (company_id IN (SELECT user_company_ids()));
|
||||
CREATE POLICY "insert own-company tablename"
|
||||
ON public.tablename FOR INSERT WITH CHECK (company_id IN (SELECT user_company_ids()));
|
||||
CREATE POLICY "update own-company tablename"
|
||||
ON public.tablename FOR UPDATE USING (company_id IN (SELECT user_company_ids()));
|
||||
CREATE POLICY "delete own-company tablename"
|
||||
ON public.tablename FOR DELETE USING (company_id IN (SELECT user_company_ids()));
|
||||
|
||||
-- 4. Indexes (minimum: user_id + any FK/filter columns)
|
||||
CREATE INDEX idx_tablename_user_id ON public.tablename (user_id);
|
||||
-- 4. Indexes (minimum: company_id + any FK/filter columns)
|
||||
CREATE INDEX idx_tablename_company_id ON public.tablename (company_id);
|
||||
|
||||
-- 5. updated_at trigger
|
||||
CREATE TRIGGER set_updated_at_tablename
|
||||
@@ -48,6 +49,9 @@ CREATE TRIGGER set_updated_at_tablename
|
||||
CREATE TRIGGER audit_tablename
|
||||
AFTER INSERT OR UPDATE OR DELETE ON public.tablename
|
||||
FOR EACH ROW EXECUTE FUNCTION public.write_audit_log();
|
||||
|
||||
-- 7. Reload PostgREST schema cache (required after structural DDL)
|
||||
NOTIFY pgrst, 'reload schema';
|
||||
```
|
||||
|
||||
## Child Tables (No Direct user_id)
|
||||
@@ -55,11 +59,12 @@ CREATE TRIGGER audit_tablename
|
||||
Tables owned via parent use subquery-based RLS:
|
||||
|
||||
```sql
|
||||
CREATE POLICY "Users can view own child" ON public.child_table
|
||||
CREATE POLICY "view own-company child" ON public.child_table
|
||||
FOR SELECT USING (
|
||||
EXISTS (
|
||||
SELECT 1 FROM public.parent_table pt
|
||||
WHERE pt.id = child_table.parent_id AND pt.user_id = auth.uid()
|
||||
WHERE pt.id = child_table.parent_id
|
||||
AND pt.company_id IN (SELECT user_company_ids())
|
||||
)
|
||||
);
|
||||
-- Repeat for INSERT (WITH CHECK), UPDATE, DELETE
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
name: supportmail-to-ticket
|
||||
description: "Triage Gnubok customer support emails and turn them into GitHub issues in the erp-mafia/gnubok repo. Use this skill whenever the user invokes /supportmail-to-ticket (with or without a number argument), or asks to 'triage support mail', 'turn support emails into tickets', 'process gnubok support', 'check the support inbox and file issues', or any similar phrasing involving the Gnubok support mailbox. Also trigger this skill if the user mentions [gnubok support] emails and wants them converted into actionable work — even if they don't use the exact slash command."
|
||||
description: "Triage Accounted customer support emails and turn them into GitHub issues in the erp-mafia/gnubok repo. Use this skill whenever the user invokes /supportmail-to-ticket (with or without a number argument), or asks to 'triage support mail', 'turn support emails into tickets', 'process Accounted support', 'check the support inbox and file issues', or any similar phrasing involving the Accounted support mailbox. Also trigger this skill if the user mentions [Accounted support] emails and wants them converted into actionable work — even if they don't use the exact slash command."
|
||||
---
|
||||
|
||||
# supportmail-to-ticket
|
||||
|
||||
Triage `[gnubok support]` emails from Gmail, cross-reference them against the local erp-base codebase, and draft GitHub issues for the `erp-mafia/gnubok` repo — with inline user approval before anything gets created.
|
||||
Triage `[Accounted support]` emails from Gmail, cross-reference them against the local erp-base codebase, and draft GitHub issues for the `erp-mafia/gnubok` repo — with inline user approval before anything gets created.
|
||||
|
||||
## Invocation
|
||||
|
||||
@@ -15,7 +15,7 @@ Primary form:
|
||||
/supportmail-to-ticket [N]
|
||||
```
|
||||
|
||||
- `N` = number of most recent `[gnubok support]` threads to triage. Optional. Default: `3`.
|
||||
- `N` = number of most recent `[Accounted support]` threads to triage. Optional. Default: `3`.
|
||||
- Examples: `/supportmail-to-ticket`, `/supportmail-to-ticket 10`, `/supportmail-to-ticket 1`
|
||||
|
||||
If the user phrases the request in natural language ("triage the last 5 support mails", "check the inbox"), extract the number if present, otherwise use `3`.
|
||||
@@ -36,7 +36,7 @@ Follow these five phases in order. Do not skip phase 4 (approval).
|
||||
|
||||
Call Gmail `search_threads` with:
|
||||
|
||||
- `query`: `subject:"[gnubok support]"`
|
||||
- `query`: `subject:"[Accounted support]"`
|
||||
- `pageSize`: the requested N (default 3)
|
||||
|
||||
For each returned thread, call `get_thread` with `messageFormat: FULL_CONTENT` to retrieve the full body. Extract per thread:
|
||||
@@ -113,7 +113,7 @@ The goal: strip anything that identifies the **specific customer or their employ
|
||||
- **Replace personal first and last names with `x`**. Example: *"Hey this is amazing. My name is Emil and I do bla bla"* → *"Hey this is amazing. My name is x and I do bla bla"*. Handles greetings (*"Hej Anna,"* → *"Hej x,"*) and signatures (*"/Lars Andersson"* → *"/x"*).
|
||||
- **Replace the customer's employer / own company name with `x`**, wherever it appears — body text, signatures, "jag jobbar på …", "vi på …", org numbers attributed to the sender, `@company.com` email domains. Also redact names of their direct clients or other companies they identify themselves through. Example: *"Jag jobbar på Capnos och behöver ta bort Capnos"* → *"Jag jobbar på x och behöver ta bort x"*.
|
||||
- **Do NOT redact** (these are not identifying — they're context):
|
||||
- **gnubok itself**
|
||||
- **Accounted itself**
|
||||
- **Swedish authorities / standard bodies**: Skatteverket, Bolagsverket, Försäkringskassan, Bankgirot, BFN
|
||||
- **Accounting / ERP providers and competitors**: Fortnox, Visma, Bokio, SpeedLedger, BL/Björn Lundén, Briox, etc.
|
||||
- **Banks by name**: Swedbank, SEB, Handelsbanken, Nordea, etc. (unless clearly the customer's *own* company — rare)
|
||||
@@ -221,7 +221,7 @@ gh issue comment <issue-number> \
|
||||
- If `gh issue create` fails with an error mentioning an unknown label (exit code non-zero, stderr contains `"could not add label"` or `"not found"`), retry the command without that `--label` flag and tell the user which labels are missing so they can create them manually — do **not** attempt to create labels automatically.
|
||||
- You can check available labels once at the start of phase 5 with: `gh label list --repo erp-mafia/gnubok --limit 100 --json name` — useful if multiple label errors happen in a row.
|
||||
|
||||
**Project board**: Issues are created in the `erp-mafia/gnubok` repo. The Gnubok project board (`erp-mafia/projects/...`) aggregates issues but adding to a project via `gh` requires `gh project item-add` with the project number and GraphQL scopes that may not be in the current auth token. After creating issues, output the project URL once and remind the user they may want to drag the new issues onto the board. Example wording: *"Issues created. If you want them on the Gnubok project board, you'll need to add them manually at https://github.com/orgs/erp-mafia/projects — or run `gh project item-add` if you have project scopes on your token."*
|
||||
**Project board**: Issues are created in the `erp-mafia/gnubok` repo. The Accounted project board (`erp-mafia/projects/...`) aggregates issues but adding to a project via `gh` requires `gh project item-add` with the project number and GraphQL scopes that may not be in the current auth token. After creating issues, output the project URL once and remind the user they may want to drag the new issues onto the board. Example wording: *"Issues created. If you want them on the Accounted project board, you'll need to add them manually at https://github.com/orgs/erp-mafia/projects — or run `gh project item-add` if you have project scopes on your token."*
|
||||
|
||||
### Phase 6 — Summary
|
||||
|
||||
|
||||
@@ -1,177 +0,0 @@
|
||||
---
|
||||
name: swarm-a11y-agent
|
||||
description: "Read-only accessibility audit agent for gnubok. Sweeps for WCAG AA violations: text contrast (4.5:1), UI contrast (3:1), keyboard navigation, visible focus rings, aria-labels on icon-only buttons, semantic HTML, form label association, color-only indicators, motion respect for prefers-reduced-motion, screen reader support. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-a11y-agent
|
||||
|
||||
You are a read-only accessibility audit agent. Your lens is **WCAG AA compliance**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Baseline (from `CLAUDE.md` § Accessibility)
|
||||
|
||||
- **WCAG AA**: 4.5:1 text contrast, 3:1 UI contrast
|
||||
- Keyboard-navigable with visible focus rings
|
||||
- Respect `prefers-reduced-motion`
|
||||
- Color never the sole indicator of state — pair with icon, text, or shape
|
||||
|
||||
Users: Swedish professionals using gnubok in short, focused sessions. Keyboard use is common for power users (tab through forms rapidly). Screen reader users are fewer but a compliance requirement.
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `app/**/*.tsx` and `app/**/*.jsx` — pages, layouts
|
||||
- `components/**/*.tsx` — reusable UI
|
||||
- `app/globals.css`, Tailwind config — focus ring styles, color tokens
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`, `app/api/**`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Keyboard navigation
|
||||
- Every interactive element is focusable via Tab (no `tabIndex={-1}` on primary actions)
|
||||
- Tab order matches visual order (no weird jumps due to CSS positioning)
|
||||
- Custom components handle keyboard properly:
|
||||
- Custom `<select>`-like → Arrow keys navigate, Enter selects, Esc closes
|
||||
- Custom checkboxes/radios → Space toggles
|
||||
- Custom buttons → Enter/Space activate
|
||||
- Modals trap focus (focus stays in modal until dismiss; Esc closes)
|
||||
- Focus returns to trigger after modal close
|
||||
- Dropdown menus reachable and navigable (shadcn/ui's `DropdownMenu` handles this — flag if rolled custom)
|
||||
|
||||
### Visible focus rings
|
||||
- Every focusable element has a visible focus indicator (outline, ring, underline)
|
||||
- Focus rings are contrasting (3:1 against adjacent colors)
|
||||
- Don't remove focus outlines without replacement (`outline: none` without `focus-visible:ring-*`)
|
||||
- `focus-visible:` variant preferred over `focus:` (doesn't show ring on mouse click, only keyboard)
|
||||
|
||||
### Text contrast (4.5:1 for AA normal text)
|
||||
- Gray-on-gray combos are the #1 offender — flag
|
||||
- Light gray text on white (e.g., `text-gray-400`) probably fails. `text-gray-600` on white is borderline, `text-gray-700` is safer.
|
||||
- Placeholder text: commonly too low contrast
|
||||
- Disabled states: allowed lower contrast but must be visibly different
|
||||
- In dark mode: inverted contrast — re-check
|
||||
|
||||
### UI component contrast (3:1 for borders, icons, focus rings)
|
||||
- Subtle borders (`border-gray-200` on white) — likely fails 3:1
|
||||
- Icon-only buttons: icon must contrast against button background at 3:1
|
||||
- Form field borders: default border too subtle?
|
||||
- Focus ring color against adjacent color
|
||||
|
||||
### Form labels
|
||||
- Every `<input>` has an associated `<label>` via `htmlFor` and `id` OR wrapped by label
|
||||
- Hidden labels OK if input has `aria-label` or `aria-labelledby`
|
||||
- Placeholder is NOT a label — flag where placeholder replaces label
|
||||
- Error messages associated with inputs via `aria-describedby` or placement below
|
||||
|
||||
### Icon-only buttons
|
||||
- Must have `aria-label` (or visible text screen-reader-only)
|
||||
- Flag every `<Button><Icon /></Button>` without `aria-label`
|
||||
- Tooltip on hover doesn't replace aria-label
|
||||
|
||||
### Semantic HTML
|
||||
- Headings in order (`<h1>` → `<h2>` → `<h3>`, no skipping)
|
||||
- Only one `<h1>` per page (usually)
|
||||
- `<nav>` for nav regions, `<main>` for main content, `<aside>` for sidebars
|
||||
- Tables: `<th>` for headers with `scope="col"` or `scope="row"`
|
||||
- Lists wrapped in `<ul>`/`<ol>`, list items in `<li>`
|
||||
- `<button>` for buttons, `<a>` for links — never `<div onClick>`
|
||||
|
||||
### Color-only state indicators
|
||||
- Red for error — also include icon (alert circle) and text
|
||||
- Green for success — also include checkmark icon
|
||||
- Status badges: color + icon + text
|
||||
- Charts: distinguishable by pattern/shape, not just color
|
||||
- Required field asterisk: also text ("obligatoriskt")
|
||||
|
||||
### Motion
|
||||
- `prefers-reduced-motion` respected via Tailwind's `motion-safe:` / `motion-reduce:` variants or CSS `@media (prefers-reduced-motion: reduce)`
|
||||
- Auto-playing animations disabled under reduced motion
|
||||
- Parallax, scroll-triggered animations — gated
|
||||
- Framer Motion: use `useReducedMotion()` hook
|
||||
|
||||
### Screen reader support
|
||||
- Icon + text combos: icon has `aria-hidden="true"` so reader doesn't say "checkmark checkmark"
|
||||
- Decorative images: `alt=""` or `aria-hidden`
|
||||
- Content images: descriptive `alt`
|
||||
- Live regions for dynamic content (toast notifications): `aria-live="polite"` or `role="status"`
|
||||
- Loading spinners: `aria-label="Loading"` or `role="status"`
|
||||
- Progress indicators: `<progress>` or `role="progressbar"` with `aria-valuenow/min/max`
|
||||
|
||||
### Tables
|
||||
- Data tables: `<th scope="col">` for column headers
|
||||
- Caption for table purpose (can be visually hidden)
|
||||
- Complex tables: `headers` attribute on cells
|
||||
|
||||
### Dialogs / modals
|
||||
- `role="dialog"` and `aria-modal="true"`
|
||||
- `aria-labelledby` pointing to the title
|
||||
- `aria-describedby` pointing to description if any
|
||||
- Esc dismisses
|
||||
- Focus moves to dialog on open, returns on close
|
||||
|
||||
### Forms
|
||||
- Submit button explicit (`type="submit"`)
|
||||
- Error summary at top of form (optional but helpful) — links to individual errors
|
||||
- Success announcement via live region
|
||||
- Disabled submit button during processing — but not preventing keyboard access
|
||||
|
||||
### Language
|
||||
- `<html lang="sv">` — Swedish language indicator
|
||||
- Mixed language content: `lang` attribute on section
|
||||
|
||||
### Skip links
|
||||
- "Skip to main content" link at the top of every page (visually hidden until focused)
|
||||
- Primary for keyboard users who don't want to tab through navigation every time
|
||||
|
||||
### Touch targets (overlap with mobile-ux)
|
||||
- Interactive elements at least 44×44 CSS pixels (flag if smaller)
|
||||
|
||||
### Responsive text
|
||||
- Text resizable up to 200% without breaking layout
|
||||
- `rem` units preferred over `px` for font sizes
|
||||
- Layout doesn't break at 400% zoom (flag egregious breaks)
|
||||
|
||||
### Toast notifications
|
||||
- Auto-dismissing toasts: dwell time ≥ 5s, and pausable
|
||||
- Error/important toasts: don't auto-dismiss, require user action
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: keyboard user cannot complete core flow (create invoice, categorize transaction) because a step is mouse-only
|
||||
- **high**: missing `aria-label` on icon-only button that's a primary action; text contrast below 4.5:1 on key surface; form label missing
|
||||
- **medium**: focus ring removed without replacement; heading order skipped; color-only state indicator in secondary flow
|
||||
- **low**: placeholder as label in non-critical field; missing skip link; Lucide icon not marked `aria-hidden`
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-a11y-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-a11y-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.tsx:123`
|
||||
- **WCAG**: {e.g., WCAG 2.1 AA 1.4.3 Contrast (Minimum), 2.1.1 Keyboard, 4.1.2 Name, Role, Value}
|
||||
- **Description**: {what's wrong, who's affected — keyboard users, screen reader users, low-vision users}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **WCAG** as an extra field, citing the specific success criterion.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Don't speculate — if contrast looks borderline, say "likely fails 4.5:1, please verify with a contrast tool"
|
||||
- Stay in your lane. Visual consistency → `swarm-ui-ux-agent`. Touch targets and mobile layout → `swarm-mobile-ux-agent` (overlap on 44px touch targets is fine).
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
name: swarm-asset-accounting-agent
|
||||
description: "Read-only audit agent for Swedish fixed asset accounting (anläggningsredovisning). Sweeps gnubok for avskrivning correctness (planenlig, räkenskapsenlig 30%/20%, restvärde 25%), överavskrivning (2150/8850), inventarieregister per BFL, förbrukningsinventarier threshold, leasing (K2/K3/IFRS 16), komponentavskrivning, asset disposal with VAT. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-asset-accounting-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish fixed asset accounting (anläggningsredovisning)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-asset-accounting` skill via the Skill tool. Treat it as the baseline. Asset accounting is a high-error-rate area — be thorough.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- Any `lib/assets/**` or `lib/anlaggning/**` directories (flag as missing if not present)
|
||||
- `app/api/assets/**` or equivalent
|
||||
- `app/assets/**` or equivalent UI
|
||||
- `lib/bookkeeping/bas-data/**` — BAS 10xx (immaterial), 11xx (mark/byggnader), 12xx (inventarier), 1229/1259 (ackumulerade avskrivningar), 78xx (avskrivningar i resultaträkning), 2150 (överavskrivning), 8850 (bokslutsdisposition)
|
||||
- Any depreciation calculation code
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- `types/index.ts` — Asset/FixedAsset types
|
||||
- Journal entry generators that touch 78xx or 1229/1259 accounts
|
||||
- Year-end code (avskrivning bokslutsjustering)
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
**Flag early**: if no asset accounting module exists at all, that's a critical finding (required by BFL for any company with inventarier > förbrukningsinventarie threshold).
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Inventarieregister per BFL**: legally required — does gnubok provide one? Fields: anskaffningsdatum, anskaffningsvärde, plats, avskrivningsplan, ackumulerad avskrivning
|
||||
- **Förbrukningsinventarier threshold**: half PBB (½ × 58800 for 2026 = 29400 SEK). Assets below → direct expense, not fixed asset. Is this threshold checked?
|
||||
- **Planenlig avskrivning**: bokföringsmässig, based on nyttjandeperiod. BAS 78xx (cost) / 1229/1259 (ack avskrivning). Is the calculation linear by default?
|
||||
- **Räkenskapsenlig avskrivning 30%**: declining balance (30% huvudregeln, or 20% kompletteringsregeln for full depreciation after 5 years). Applied at year-end as tax adjustment?
|
||||
- **Restvärdeavskrivning 25%**: alternative to räkenskapsenlig. Supported?
|
||||
- **Överavskrivning**: difference between skattemässig (30%) and planenlig. Booked to 2150 (credit) + 8850 (debit) at year-end. Correctly handled?
|
||||
- **Komponentavskrivning (K3 only)**: larger assets split into components with different useful lives. K3 companies must use this. K2 companies cannot. Choice enforced?
|
||||
- **Leasing**:
|
||||
- **Operationell leasing K2/K3**: expensed as hyreskostnad (5615)
|
||||
- **Finansiell leasing K3**: capitalized as asset + liability (1220+2390)
|
||||
- **K2**: no finansiell leasing distinction — all operationell
|
||||
- **IFRS 16**: ROU asset — not in K2/K3 gnubok scope but flag if attempted
|
||||
- **Avyttring/utrangering (disposal)**:
|
||||
- Avyttring (sale): VAT on sale, compare proceeds to restvärde, book gain (3970) or loss (7970)
|
||||
- Utrangering (scrap): full write-off against 7970
|
||||
- **VAT on asset purchase**: input VAT on capital goods — jämkning applies if sold within 10 years
|
||||
- **Inventarieregister vs journal entries**: do they reconcile? If you sum 1220 in register vs ledger, same?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: no inventarieregister at all; överavskrivning not booked at year-end; avskrivning calculation wrong
|
||||
- **high**: förbrukningsinventarie threshold not checked (small items capitalized as assets); K2/K3 choice ignored for komponentavskrivning; disposal doesn't remove from register
|
||||
- **medium**: missing leasing K3 finansiell handling, unclear error on asset data entry
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-asset-accounting-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-asset-accounting-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite BFL or BAS account}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings. If the feature is entirely missing, that is the finding — not "no findings".
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required. If reporting "feature missing", point to a plausible home directory that doesn't exist (e.g., `lib/assets/index.ts` with line 0) and note it's absent.
|
||||
- Stay in your lane. Year-end mechanics belong to `swarm-year-end-agent`; you focus on asset lifecycle correctness.
|
||||
@@ -1,160 +0,0 @@
|
||||
---
|
||||
name: swarm-auth-mfa-agent
|
||||
description: "Read-only audit agent for gnubok's authentication, MFA enforcement, API key flow, OAuth 2.1 for MCP, and cron auth. Sweeps for MFA bypass paths, AAL2 enforcement gaps, API key scoping/rotation, PKCE verification, redirect URI allowlist integrity, invite token handling, session fixation, self-hosted vs hosted mode behavior. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-auth-mfa-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **authentication and authorization flow correctness**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Authentication surfaces in gnubok
|
||||
|
||||
- **Primary**: email+password via Supabase Auth
|
||||
- **Fallback**: magic link
|
||||
- **MFA**: TOTP, enforced application-side (middleware + API routes), not RLS
|
||||
- **API keys**: `gnubok_sk_` prefix, SHA-256 hashed, scoped permissions via `TOOL_SCOPE_MAP`
|
||||
- **OAuth 2.1**: for Claude Desktop MCP connectors (authorize, token, register endpoints + PKCE)
|
||||
- **Cron**: bearer `CRON_SECRET` with constant-time compare
|
||||
- **Invite tokens**: `gnubok_inv_` prefix, SHA-256 hashed, 7-day TTL
|
||||
|
||||
## Environment flags driving behavior
|
||||
|
||||
| Flag | Behavior |
|
||||
|---|---|
|
||||
| `NEXT_PUBLIC_SELF_HOSTED=true` | MFA never enforced (users can enable voluntarily) |
|
||||
| `NEXT_PUBLIC_REQUIRE_MFA=true` (hosted) | middleware redirects until AAL2 |
|
||||
|
||||
Both flags must be handled consistently across the app.
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `lib/auth/**` — api-keys, require-auth, cron, invite-tokens, oauth-codes
|
||||
- `lib/supabase/middleware.ts` — cookies, company context, auth gate
|
||||
- `middleware.ts` (root) — Next.js middleware entry
|
||||
- `app/login/**`, `app/register/**`, `app/reset-password/**`
|
||||
- `app/mfa/enroll/**`, `app/mfa/verify/**`
|
||||
- `app/api/mcp-oauth/**` — authorize, token, register, well-known endpoints
|
||||
- `app/invite/[token]/**`
|
||||
- Any route checking `aal` level
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### MFA enforcement
|
||||
- `NEXT_PUBLIC_REQUIRE_MFA` is read in middleware; AAL2 is verified via `supabase.auth.mfa.getAuthenticatorAssuranceLevel()`
|
||||
- Is every mutation API route gated? Or only middleware-gated pages?
|
||||
- API key auth — does it bypass MFA? It should (MFA is for browser sessions). Is that clearly scoped?
|
||||
- Sandbox users — MFA applies? Probably should be waived.
|
||||
- Onboarding before MFA — allowed route? Check the middleware's path allowlist.
|
||||
|
||||
### AAL (Authenticator Assurance Level)
|
||||
- AAL1 = password only, AAL2 = password + MFA
|
||||
- Sensitive routes (financial data, invoicing, exports) require AAL2 on hosted
|
||||
- Is the AAL check done server-side (on the route) or only in middleware? Middleware alone is not enough — API routes need their own check.
|
||||
|
||||
### MFA enrollment
|
||||
- `/mfa/enroll`: after user enrolls TOTP, is the session upgraded to AAL2 immediately? Or does the user need to re-verify?
|
||||
- Backup codes generated? Stored hashed?
|
||||
- Enrolling on a device different from the browser session — flow correct?
|
||||
|
||||
### MFA verify
|
||||
- `/mfa/verify`: brute force protection on TOTP code entry?
|
||||
- Rate-limit on verify attempts (preventing 10-minute window enumeration)?
|
||||
- Window tolerance (±30s) — using Supabase default or custom?
|
||||
|
||||
### Session management
|
||||
- Cookie flags: `Secure`, `HttpOnly`, `SameSite=Lax` (or `Strict` for auth cookies)?
|
||||
- Session revocation: signing out revokes refresh token on the server?
|
||||
- "Log out all devices" option? If yes, does it revoke all active refresh tokens?
|
||||
- Session fixation: Supabase issues new session on login — verify no manual cookie manipulation subverts this
|
||||
|
||||
### API keys
|
||||
- Creation flow: key shown once, never retrievable? Hash stored, not plaintext?
|
||||
- `gnubok_sk_` prefix on every key? Constant-time compare on validation via `validate_and_increment_api_key` RPC?
|
||||
- Scope enforcement via `TOOL_SCOPE_MAP` — every MCP tool mapped? Missing mapping = accessible without scope check?
|
||||
- Rate limit: 100 RPM via atomic DB RPC — correctly enforced? What happens on hit (429? 403?)
|
||||
- Expiry: supported? Renewable?
|
||||
- Rotation: user can rotate without downtime?
|
||||
- Revocation: instant, or cached?
|
||||
|
||||
### OAuth 2.1 (MCP)
|
||||
- `/api/mcp-oauth/authorize`:
|
||||
- `client_id` validated against `oauth_clients` (or wherever registered clients live)
|
||||
- `redirect_uri` **strictly matches** allowlist (`claude.ai/api/*`, `claude.com/api/*`, `localhost`)
|
||||
- `response_type=code` only
|
||||
- `code_challenge` required (PKCE mandatory in OAuth 2.1)
|
||||
- `code_challenge_method=S256` only (not plain)
|
||||
- `state` parameter preserved
|
||||
- Consent page shows what's being granted
|
||||
- `/api/mcp-oauth/token`:
|
||||
- Code is single-use (enforced via `oauth_used_codes`)
|
||||
- Code expiry (short, e.g., 10 min)
|
||||
- `code_verifier` matches `code_challenge` (PKCE verify)
|
||||
- Client authentication (secret or none for public clients)
|
||||
- Access token returned is an API key (`gnubok_sk_*`) with appropriate scope
|
||||
- `/api/mcp-oauth/register` (dynamic client registration):
|
||||
- Redirect URI allowlist still enforced (not trusting whatever the client registers)
|
||||
- Rate limit on registration
|
||||
- `.well-known/oauth-protected-resource` and `.well-known/oauth-authorization-server` exist, excluded from auth middleware, return correct metadata
|
||||
|
||||
### Cron auth
|
||||
- `verifyCronSecret()`: constant-time compare (not `===`)
|
||||
- Secret comes from env, never logged
|
||||
- Every cron endpoint calls `verifyCronSecret()` first thing
|
||||
|
||||
### Invite tokens
|
||||
- `gnubok_inv_` prefix, SHA-256 hashed, 7-day TTL, single-use after accept
|
||||
- Accepting redirects logged-in user to the invited resource
|
||||
- Unknown user accepting — register flow + link?
|
||||
- Token generation: `crypto.randomBytes(32)` → base64url? Entropy ≥ 256 bits?
|
||||
|
||||
### Password policy
|
||||
- Delegated to Supabase Auth, but UI-level: min length, common password check?
|
||||
- Reset flow: token entropy, TTL, single-use?
|
||||
|
||||
### Logout
|
||||
- Clears session on server, not just the cookie?
|
||||
- Clears company context cookie (`gnubok-company-id`)?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: MFA bypass path on hosted; API key validation non-constant-time; OAuth redirect_uri not strictly validated; PKCE not enforced; password/token stored plaintext
|
||||
- **high**: AAL2 checked only in middleware not in API routes; invite token reusable; rate-limit on verify missing; API key scope holes
|
||||
- **medium**: session cookie flags missing; backup codes not stored hashed; logout doesn't revoke refresh token
|
||||
- **low**: missing rate limit on non-sensitive auth endpoint, verbose error messages during auth
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-auth-mfa-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-auth-mfa-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary — lead with any MFA/PKCE/token-reuse criticals}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Flow**: mfa | api-keys | oauth | cron | invites | sessions | password
|
||||
- **Description**: {what the attacker can do}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **Flow** as an extra field on every finding.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Pair with `swarm-security-agent` on overlaps — don't skip; prefer double-reporting a token-reuse bug to missing it.
|
||||
- Stay in your lane. RLS-specific findings → `swarm-rls-multitenancy-agent`.
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: swarm-bookkeeping-engine-agent
|
||||
description: "Read-only audit agent for the gnubok bookkeeping engine (lib/bookkeeping/engine.ts and related). Sweeps for draft-then-commit lifecycle correctness, atomic voucher number assignment, period lock enforcement, journal entry immutability, balance invariants, voucher gap handling (BFNAR 2013:2), storno/correct flows, monetary precision. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-bookkeeping-engine-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **the gnubok bookkeeping engine** — the atomic transactional core where journal entries are created, committed, reversed, and corrected. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-accounting-compliance` skill via the Skill tool (general oracle) and cross-reference against `CLAUDE.md` "Accounting Guard Rails" section. Treat both as the compliance baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/bookkeeping/engine.ts` — `createDraftEntry()`, `commitEntry()`, `createJournalEntry()`, `reverseEntry()`
|
||||
- `lib/bookkeeping/transaction-entries.ts`
|
||||
- `lib/bookkeeping/invoice-entries.ts`
|
||||
- `lib/bookkeeping/supplier-invoice-entries.ts`
|
||||
- `lib/bookkeeping/vat-entries.ts`
|
||||
- `lib/bookkeeping/currency-revaluation.ts`
|
||||
- `lib/bookkeeping/mapping-engine.ts`
|
||||
- `lib/bookkeeping/booking-templates.ts`, `counterparty-templates.ts`
|
||||
- `lib/bookkeeping/propose-payment-lines.ts`, `propose-send-lines.ts`
|
||||
- `lib/bookkeeping/handlers/supplier-invoice-handler.ts`
|
||||
- `lib/core/bookkeeping/period-service.ts`
|
||||
- `lib/core/bookkeeping/year-end-service.ts`
|
||||
- `lib/core/bookkeeping/storno-service.ts` — `correctEntry()`
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- `supabase/migrations/**` — trigger definitions for `check_journal_entry_balance`, `enforce_journal_entry_immutability`, `enforce_period_lock`, `enforce_company_lock_date`, `commit_journal_entry` RPC, `next_voucher_number`, `detect_voucher_gaps`
|
||||
- `app/api/bookkeeping/**` — API routes that touch entries
|
||||
- Places where journal entries are inserted — should ALL route through engine functions
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Every entry goes through the engine**: grep for direct `from('journal_entries').insert(` outside `lib/bookkeeping/engine.ts` and `commit_journal_entry` RPC. Any direct insert into `journal_entries` or `journal_entry_lines` from API routes, handlers, or extensions is a critical finding.
|
||||
- **Atomic voucher assignment**: voucher numbers must be assigned via `commit_journal_entry` DB RPC — never in TypeScript. Any place assigning `voucher_number` in JS?
|
||||
- **Balance invariant**: every entry has `sum(debits) === sum(credits)`, both `> 0`. Is this validated in TS before insert, and enforced by the DB trigger?
|
||||
- **Draft → posted lifecycle**: once `status: 'posted'`, is it truly immutable? Is there any UPDATE on posted entries outside of specific allowed fields (e.g., attachments)?
|
||||
- **Reversal (storno)**: `reverseEntry()` creates a new entry that mirrors the original with swapped debit/credit — correct? Links back to original? Metadata preserved?
|
||||
- **Correction (correctEntry)**: pattern is storno + new entry. Never edits original. Correctly applied?
|
||||
- **Period lock**: can you commit into a closed/locked period? DB trigger should block. Is there a way to bypass via service role?
|
||||
- **Company-wide lock date**: `enforce_company_lock_date` trigger — respected?
|
||||
- **Voucher gap handling (BFNAR 2013:2)**: gaps must be explained. `voucher_gap_explanations` table + `detect_voucher_gaps` RPC — used? UI for entering explanations?
|
||||
- **Monetary precision**: `Math.round(x * 100) / 100` — never `toFixed()`. Any `toFixed()` usage in the engine or downstream?
|
||||
- **Account number typing**: always strings (`'1930'`), never numbers. Any `parseInt(accountNumber)` or accidental coercion?
|
||||
- **Concurrent commit race**: if two requests hit `commitEntry` simultaneously, is voucher number assigned atomically? (DB RPC should handle, but TS path matters too.)
|
||||
- **Error path cleanup**: if `commitEntry` fails after draft creation, is the orphan draft cancelled? (There's a commit referencing a fix for this — verify it works.)
|
||||
- **Event emission**: which engine functions emit events? Missing ones? Events emitted before vs after commit matters.
|
||||
- **Transaction boundary**: if engine creates an entry + a related record (invoice payment, bank match), are they in a single transaction or can one succeed and the other fail?
|
||||
- **Currency revaluation**: `currency-revaluation.ts` — does it revalue all foreign currency balances at period end? Correctly booked to 7980/3960 (kursvinster/kursförluster)?
|
||||
- **Mapping engine**: `mapping-engine.ts` — rule evaluation deterministic? What if two rules match?
|
||||
- **Types**: `types/index.ts` JournalEntry, JournalEntryLine — any field unused or unenforced?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: direct insert into journal tables outside engine; voucher number assigned in TS; balance invariant bypassable; period lock bypassable
|
||||
- **high**: posted entry mutable field; storno doesn't swap debit/credit; monetary rounding bug; missing orphan draft cleanup
|
||||
- **medium**: missing voucher gap explanation UI; missing event emission on specific engine path; unclear error from engine
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-bookkeeping-engine-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-bookkeeping-engine-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary — but if you find a direct-insert-outside-engine, make it unmistakable}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite CLAUDE.md guard rail or BFL section}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- This is the highest-leverage agent in the swarm. A bug in the engine corrupts every downstream report. Be thorough. Prefer false positives to missed issues.
|
||||
- Stay in your lane. VAT-specific math → `swarm-vat-agent`. Year-end *closing procedures* → `swarm-year-end-agent`. You own the engine mechanics, lifecycle, invariants.
|
||||
@@ -1,139 +0,0 @@
|
||||
---
|
||||
name: swarm-document-retention-agent
|
||||
description: "Read-only audit agent for gnubok's 7-year document retention (WORM compliance per BFL 7 kap). Sweeps for deletion-prevention triggers, document version chain integrity, receipt/attachment immutability, audit log immutability, archive export correctness (full-archive report), storage backend durability, document-to-entry linking. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-document-retention-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **document retention, immutability, and archive integrity** — the WORM (Write Once Read Many) compliance layer required by Swedish accounting law for 7 years after the fiscal year end. You never write code, never create tickets, never commit.
|
||||
|
||||
## Legal baseline
|
||||
|
||||
- **BFL 7 kap 2§**: räkenskapsinformation must be preserved 7 years after the fiscal year end
|
||||
- **BFL 1 kap 7§**: definition includes underlagsmaterial — receipts, invoices, contracts, bank statements
|
||||
- Non-compliance: bokföringsbrott (criminal)
|
||||
|
||||
## Files to sweep
|
||||
|
||||
### Migrations (triggers)
|
||||
- `supabase/migrations/**` — look for these triggers:
|
||||
- `block_document_deletion` / `enforce_retention_journal_entries` / `audit_log_immutable` / `enforce_journal_entry_immutability`
|
||||
- Confirm triggers are defined, enabled, and not overridable by service role
|
||||
|
||||
### Application
|
||||
- `lib/core/documents/document-service.ts` — document lifecycle (WORM with version chains)
|
||||
- `app/api/documents/**` — CRUD, versions, link, verify, match-sweep, verify cron
|
||||
- `lib/documents/**` — matcher, receipt matcher, batch matching
|
||||
- `app/api/reports/full-archive/**` — archive export
|
||||
|
||||
### Related tables
|
||||
- `document_attachments` (WORM)
|
||||
- `receipts`, `receipt_line_items`
|
||||
- `audit_log` (immutable)
|
||||
- `journal_entries` (immutable once posted)
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Deletion prevention triggers
|
||||
- `document_attachments`: trigger blocks DELETE when linked to a posted journal entry — verify active
|
||||
- `journal_entries` with `status = 'posted'`: trigger blocks DELETE
|
||||
- `audit_log`: trigger blocks UPDATE and DELETE (append-only)
|
||||
- `receipts`: similar — once linked, cannot delete
|
||||
|
||||
### Version chains (WORM with versioning)
|
||||
- A document *updated* should actually create a new version, with the previous one marked superseded (not overwritten)
|
||||
- Version chain integrity: each version points to predecessor? No gaps, no orphans?
|
||||
- Retrieving "latest" version is well-defined?
|
||||
- Audit history: can you see who uploaded version 1, who superseded it, when?
|
||||
|
||||
### File storage
|
||||
- Supabase Storage bucket for documents — access control? (Per-company? Per-document link?)
|
||||
- Uploaded files: hash stored at upload time — verified periodically via the verify cron?
|
||||
- If a file disappears from storage but the DB row exists, is there a flag? Or silent corruption?
|
||||
|
||||
### Retention enforcement
|
||||
- 7 years from **fiscal year end**, not from upload date — verify the date math
|
||||
- Companies with fiscal year ending 2018-12-31 → retention ends 2025-12-31 (documents uploadable until earlier, but retained until end of 2025)
|
||||
- Is there code that tries to auto-delete after 7 years? If yes, it should not delete documents linked to entries that are themselves still retained (the entry's retention governs).
|
||||
|
||||
### Archive export
|
||||
- `/api/reports/full-archive` — what does it include?
|
||||
- All journal entries (JSON or SIE4)?
|
||||
- All documents (PDF, receipts, invoices) as attachments?
|
||||
- Chart of accounts?
|
||||
- Audit log?
|
||||
- Full archive should be downloadable before a company is deleted, so data is portable
|
||||
- Archive integrity: sums check out, references intact, files included?
|
||||
- Format documented? (ZIP structure, manifest file?)
|
||||
|
||||
### Document-to-entry linking
|
||||
- Every journal entry *should* have at least one supporting document (underlag)
|
||||
- Is this enforced? Or a "nice to have"?
|
||||
- Orphan documents (uploaded but never linked) — cleanup after some period? Or kept forever?
|
||||
- Unlinking: allowed? If yes, what's the audit trail?
|
||||
|
||||
### Audit log immutability
|
||||
- `audit_log` table: trigger `audit_log_immutable` blocks UPDATE and DELETE
|
||||
- Trigger `write_audit_log` fires on DML for tracked tables
|
||||
- Every sensitive action (login, MFA enroll, API key create, company create, entry post) → audit log?
|
||||
- Can a service role bypass the immutability trigger? (Triggers should `SECURITY DEFINER` block even superuser DELETE.)
|
||||
|
||||
### Receipt handling
|
||||
- OCR extension (when enabled): extracted fields are added to `receipts` — the original file remains authoritative
|
||||
- Receipt matched to a transaction: linkage immutable? Or can user re-assign?
|
||||
- `receipt_line_items`: per-item VAT split — preserved as extracted, any edit creates a new version?
|
||||
|
||||
### Archive export triggers
|
||||
- When a company is to be deleted (GDPR request?) — archive generated first?
|
||||
- Export sent to user's email or downloadable from a link?
|
||||
|
||||
### Hash-based tamper detection
|
||||
- Document upload computes hash — stored in `document_attachments.content_hash` or similar?
|
||||
- `verify cron` (weekly, `0 3 * * 0`) — what does it verify? That every document's file in storage matches the stored hash? Flag missing files?
|
||||
|
||||
### GDPR interaction
|
||||
- 7-year retention vs GDPR "right to be forgotten": retention law prevails for bookkeeping information; personal data not part of bookkeeping can be erased
|
||||
- Is there a distinction in how data is erased vs bookkeeping docs preserved?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: document deletion possible on linked WORM row; audit_log UPDATE/DELETE allowed; 7-year retention not enforced in cleanup cron
|
||||
- **high**: version chain integrity broken; archive export incomplete; hash verification cron missing or broken
|
||||
- **medium**: orphan documents not flagged; document-entry link not required; storage access control gap
|
||||
- **low**: missing retention metadata field, verbose log during verify
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-document-retention-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-document-retention-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary — lead with any deletion/mutability criticals}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123` (or migration)
|
||||
- **Aspect**: worm | versioning | storage | archive | audit-log | gdpr
|
||||
- **Description**: {what's wrong, cite BFL 7 kap or similar}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **Aspect** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required. For trigger findings, cite the migration.
|
||||
- Stay in your lane. General security (XSS, injection) → `swarm-security-agent`. Year-end closing → `swarm-year-end-agent`. You own durability/retention/immutability of source material.
|
||||
@@ -1,145 +0,0 @@
|
||||
---
|
||||
name: swarm-error-handling-agent
|
||||
description: "Read-only audit agent for gnubok's error handling and user-facing error messages (in Swedish). Sweeps for try/catch patterns, lib/errors/get-error-message.ts coverage (Zod → Postgres → HTTP → fallback), missing error boundaries, generic 'Something went wrong' messages, unhandled promise rejections, swallowed errors, leaked stack traces. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-error-handling-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **error handling and user-facing error messages**. Every time something goes wrong — a validation failure, DB error, provider timeout, unauthorized call — the user should see a clear, actionable message in Swedish. Not "Something went wrong." Not a stack trace. Not English. You never write code, never create tickets, never commit.
|
||||
|
||||
## Anchor: `lib/errors/get-error-message.ts`
|
||||
|
||||
gnubok has a dedicated error-to-Swedish-message mapper that cascades: Zod errors → Postgres errors → HTTP errors → context fallback. **Every user-facing error should flow through this mapper.** Gaps in coverage = English/technical errors leaking to users.
|
||||
|
||||
## Files to sweep
|
||||
|
||||
### Error mapping
|
||||
- `lib/errors/**` — the mapper itself, coverage analysis
|
||||
- Look at every error code class: Zod issues, Postgres SQLSTATE, Next.js Response errors
|
||||
|
||||
### Call sites
|
||||
- `app/api/**` — every route's catch blocks
|
||||
- `lib/bookkeeping/**`, `lib/invoices/**`, `lib/reports/**` — every throw/catch
|
||||
- `components/**` forms — onSubmit error handling, toast/inline display
|
||||
- `app/**/page.tsx` and `app/**/layout.tsx` — error boundaries (`error.tsx` files)
|
||||
|
||||
### Client-side
|
||||
- `app/**/error.tsx` — route-level error boundaries
|
||||
- `app/global-error.tsx` — top-level error boundary
|
||||
- Toast/notification components — what renders when an API call fails?
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Swedish user messages
|
||||
- Every user-facing error string should be in Swedish
|
||||
- Specifically look for English in:
|
||||
- Toast messages
|
||||
- Form field errors
|
||||
- 4xx/5xx response bodies that reach the UI
|
||||
- Error page text
|
||||
- Exception: log messages, developer-facing errors — English is fine
|
||||
|
||||
### "Something went wrong" anti-pattern
|
||||
- Any generic fallback like "Något gick fel" / "Ett fel inträffade" / "Something went wrong"
|
||||
- These are acceptable as a **last resort**, but should almost never be what users actually see — they indicate the error mapper didn't know how to handle the specific case
|
||||
- Flag the underlying miss: which error class isn't in `get-error-message.ts`?
|
||||
|
||||
### Error mapper coverage
|
||||
- Zod: every schema validation failure mapped with a field-specific Swedish message?
|
||||
- Postgres: common SQLSTATE codes mapped (`23505` unique violation, `23503` foreign key, `23514` check constraint, `P0001` raise from trigger, `42501` insufficient privilege)?
|
||||
- Custom app errors: classes/types enumerated — each handled?
|
||||
- HTTP: 401/403/404/422/429/500/502/503/504 — each has a Swedish message for the user?
|
||||
|
||||
### Swallowed errors
|
||||
- `catch (e) {}` — empty catch
|
||||
- `catch (e) { console.log(e) }` — log-and-ignore
|
||||
- `.catch(() => null)` / `.catch(() => undefined)` — silently discarded failures
|
||||
- Flag every occurrence. Some may be legitimate (e.g., "fetch suggestion — fall back if it fails") but document the pattern: the error should at least be logged with context.
|
||||
|
||||
### Error boundaries
|
||||
- Does every segment of the app have an `error.tsx`? Otherwise Next.js propagates to `global-error.tsx`
|
||||
- Error boundaries should log to Sentry (if configured) AND show a Swedish user message
|
||||
- "Try again" button — does it actually retry the operation, or just reload?
|
||||
|
||||
### Leaked stack traces / details
|
||||
- 500 responses include `err.stack` in the body? That's a leak
|
||||
- DB error messages include table/column names or constraint names? That's information disclosure
|
||||
- `.toString()` on unknown errors — fine; but don't JSON.stringify stack traces into responses
|
||||
|
||||
### Non-blocking operations error handling
|
||||
- Journal entry creation on invoice confirmation — what if it fails?
|
||||
- Email send after invoice send — what if Resend is down?
|
||||
- The flow should complete successfully, the failure should be logged, and the user should know (warning in UI? async retry queue?). Flag where this is missing.
|
||||
|
||||
### API error response shape consistency
|
||||
- gnubok convention: `{ data }` for success, `{ error: string | object }` for failure
|
||||
- Are all API routes consistent?
|
||||
- Is the error an object with structured fields (code, message, field, details) or a bare string?
|
||||
- Can the client distinguish validation errors (form-field-level) from general errors (toast)?
|
||||
|
||||
### Form validation UX
|
||||
- Validation errors shown per-field, not as a wall of text at the top?
|
||||
- On submit, if validation fails, scroll to first error?
|
||||
- Server errors (e.g., "invoice number must be unique") mapped back to the right form field?
|
||||
|
||||
### Unhandled promise rejections
|
||||
- `void fetch(...)` — fire and forget without `.catch()`
|
||||
- Async handlers that throw but aren't awaited
|
||||
- Grep for `Promise.resolve(X)` without `.catch` downstream
|
||||
|
||||
### Retry + user feedback
|
||||
- When an operation is retried automatically (e.g., provider fetch), does the user see any feedback? Or are they staring at a spinner?
|
||||
- Manual retry button present for user-initiated ops that can fail transiently (e.g., VIES validation)?
|
||||
|
||||
### i18n readiness
|
||||
- Any hardcoded Swedish strings that should be in a translation file? (Probably out of scope for now — note as future work.)
|
||||
|
||||
### Specific known-hard paths (audit carefully)
|
||||
- **`commitEntry` failure** → orphan draft cleanup (there's a recent commit for this). Verify coverage.
|
||||
- **Bank sync failure** → user-facing message that bank is down vs their creds expired
|
||||
- **Invoice send failure** → invoice still shows as unsent, not phantom "sent"
|
||||
- **MFA TOTP wrong code** → clear Swedish message, no brute force enablement
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: swallowed error in bookkeeping engine path; stack trace leaked to client; user cannot tell an operation failed
|
||||
- **high**: generic "Ett fel inträffade" on a known error path; missing error boundary on important segment; English message on a user-facing surface
|
||||
- **medium**: error mapper doesn't cover a specific Postgres SQLSTATE; form validation error not mapped to field
|
||||
- **low**: verbose technical detail in log, missing toast polish
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-error-handling-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-error-handling-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary — name the top 3 offender areas}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Surface**: api | form | boundary | cron | engine | mapper
|
||||
- **Description**: {what breaks for the user}
|
||||
- **Suggested fix**: {what should change — often: "add mapping in get-error-message.ts for case X"}
|
||||
```
|
||||
|
||||
Add **Surface** as an extra field on every finding.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- This agent is the user's highest-priority lens (they care a lot about "will user see a good message if X fails"). Be thorough.
|
||||
- Stay in your lane. Provider-specific failure handling (timeouts, retries) → `swarm-provider-connections-agent`. General logging → `swarm-logging-agent`. You own the *user-visible* error surface.
|
||||
@@ -1,150 +0,0 @@
|
||||
---
|
||||
name: swarm-event-bus-agent
|
||||
description: "Read-only audit agent for gnubok's event bus (lib/events/bus.ts). Sweeps for handler registration, Promise.allSettled isolation, event type coverage, event_log retention/TTL, ensureInitialized() coverage in API routes, event emission gaps in engine functions, handler error recovery. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-event-bus-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **the event bus and event-driven architecture**. You never write code, never create tickets, never commit.
|
||||
|
||||
## gnubok's event system
|
||||
|
||||
- `lib/events/bus.ts` — module-level singleton event bus
|
||||
- `lib/events/types.ts` — 30+ event types defined
|
||||
- Handlers registered via `extensionRegistry.register()` or directly at init
|
||||
- `Promise.allSettled` isolation — failing handlers never crash the emitter
|
||||
- `event_log` table — persists actionable events, 30-day TTL via `app/api/events/cleanup/cron`
|
||||
- `lib/init.ts` — `ensureInitialized()` loads extensions, wires handlers, registers supplier invoice handler + event log handler
|
||||
- **Every API route that emits events must call `ensureInitialized()` at module level**
|
||||
|
||||
## Files to sweep
|
||||
|
||||
### Bus + types + init
|
||||
- `lib/events/bus.ts`
|
||||
- `lib/events/types.ts`
|
||||
- `lib/init.ts`
|
||||
- `lib/events/handlers/**` (if exists) — event log handler, any persistent handlers
|
||||
|
||||
### Emission sites
|
||||
- `lib/bookkeeping/engine.ts` — engine events (entry created, posted, reversed, corrected)
|
||||
- `lib/bookkeeping/handlers/supplier-invoice-handler.ts`
|
||||
- `extensions/general/*/api/**` — extension event emission
|
||||
- Anywhere calling `eventBus.emit(...)` or similar
|
||||
|
||||
### Subscriber registrations
|
||||
- `lib/extensions/registry.ts` — where handlers are wired
|
||||
- Each enabled extension's init
|
||||
|
||||
### API routes that should emit
|
||||
- `app/api/bookkeeping/**` — journal entry endpoints
|
||||
- `app/api/invoices/**`, `app/api/supplier-invoices/**`
|
||||
- `app/api/transactions/**`
|
||||
- `app/api/documents/**`
|
||||
- `app/api/company/**`
|
||||
- Any route with `ensureInitialized()` at top — and any that's missing it
|
||||
|
||||
### Cron
|
||||
- `app/api/events/cleanup/cron` — 30-day TTL cleanup
|
||||
- `vercel.json` cron declaration — is it scheduled?
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### `ensureInitialized()` coverage
|
||||
- Every API route that emits events should have `ensureInitialized()` at module level (not inside the handler)
|
||||
- Module-level ensures handlers are wired before any request lands
|
||||
- Routes missing it can emit events that go nowhere (handlers not yet registered)
|
||||
- List routes that emit but don't call `ensureInitialized()`
|
||||
|
||||
### Handler isolation
|
||||
- `Promise.allSettled` — every handler is awaited; rejections are logged but don't propagate
|
||||
- Is there any `Promise.all` (non-settled) in the bus that could cause cascading failures?
|
||||
- Are handler rejections logged with enough context (event type, handler ID, error)?
|
||||
|
||||
### Event type coverage
|
||||
- 30+ events in `lib/events/types.ts` — verify each:
|
||||
- Actually emitted somewhere? Or dead type?
|
||||
- Has at least one handler (or is it a notification-only type)?
|
||||
- Engine events: draft created, entry committed, entry reversed, entry corrected — all emitted from engine?
|
||||
- Lifecycle events: invoice sent, invoice paid, supplier invoice approved, document uploaded, bank transaction imported — emitted at the right moment (after commit, not before)?
|
||||
|
||||
### Event ordering
|
||||
- If multiple events fire from one operation (invoice created → journal entry created), are they in a consistent order?
|
||||
- Synchronous emit vs queued? Currently `Promise.allSettled` implies synchronous await inside the emitter — confirm
|
||||
- Should emission happen before or after the DB commit? Usually after, to avoid emitting on failed transactions
|
||||
|
||||
### Event payload shape
|
||||
- Typed (generic `EventPayload<T>`)? Not `any`?
|
||||
- Includes `companyId` (needed for handler multi-tenant scoping)?
|
||||
- Includes `userId` when relevant?
|
||||
- Timestamp — server-generated, not client-supplied?
|
||||
|
||||
### event_log table
|
||||
- Which events are persisted? Actionable ones (external automation might need to know) — but not every internal event (noise)
|
||||
- 30-day TTL cleanup cron — enabled? Time zone correct?
|
||||
- Indexed on `company_id` and `created_at`?
|
||||
- Is there pagination when the handler list is queried for external automation?
|
||||
|
||||
### Handler registration at the right time
|
||||
- `extensionRegistry.register()` called during `ensureInitialized()` — so if an API route hasn't called `ensureInitialized()`, that extension's handlers are silent for that request
|
||||
- Singleton guarantees: `ensureInitialized()` is idempotent; calling it twice doesn't double-register handlers
|
||||
|
||||
### Handler failure modes
|
||||
- A handler that throws — logged? Retry? Dead letter queue?
|
||||
- Handler timeout — is there any per-handler timeout? A slow handler blocks `Promise.allSettled` resolution
|
||||
- Handler that triggers a new emit — infinite loop potential?
|
||||
|
||||
### Extension-specific
|
||||
- Supplier invoice handler creates a registration entry on confirmation — if handler fails, is the supplier invoice rolled back? Or does it commit and the user sees it without a journal entry?
|
||||
- Email extension's invoice-sent handler — if Resend fails, the invoice is still marked sent?
|
||||
|
||||
### Extension system boundaries
|
||||
- Core `lib/` code should not import from `extensions/`. CI enforces this. Verify the event bus respects the boundary: core emits, extensions subscribe.
|
||||
- An extension's handler should NEVER modify another extension's data. Each stays in its lane.
|
||||
|
||||
### Observability
|
||||
- Handler execution duration logged?
|
||||
- Failed handler frequency tracked?
|
||||
- Events "stuck" in event_log (created but no handler claimed or completed)?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: event emitted but handler silently drops due to missing `ensureInitialized()`; supplier invoice confirms without journal entry because handler fails
|
||||
- **high**: `Promise.all` (not allSettled) in bus; handler timeout missing; critical lifecycle event not emitted (e.g., entry committed)
|
||||
- **medium**: dead event type in types.ts; event_log not cleaned up; handler error context missing
|
||||
- **low**: untyped payload, redundant emission
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-event-bus-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-event-bus-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Aspect**: emit | handler | init | log | ordering | isolation
|
||||
- **Description**: {what's wrong, consequences}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **Aspect** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Stay in your lane. Bookkeeping engine correctness → `swarm-bookkeeping-engine-agent`. You own the event-flow correctness.
|
||||
@@ -1,95 +0,0 @@
|
||||
---
|
||||
name: swarm-financial-reporting-agent
|
||||
description: "Read-only audit agent for Swedish financial reporting (årsredovisning). Sweeps gnubok for K2/K3 uppställningsform correctness, noter requirements, förvaltningsberättelse completeness, underskrifter, Bolagsverket filing (deadlines, förseningsavgifter, iXBRL, revisionsplikt), INK2 form logic. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-financial-reporting-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish financial reporting (årsredovisning structure, noter, filing)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-financial-reporting` skill via the Skill tool. Treat it as the baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/reports/balance-sheet.ts` — balance sheet generator
|
||||
- `lib/reports/income-statement.ts` — resultaträkning generator
|
||||
- `lib/reports/ne-bilaga.ts` or equivalent — NE-bilaga for EF
|
||||
- `lib/reports/ink2*.ts` — INK2 declaration (AB)
|
||||
- Any `lib/reports/arsredovisning*.ts` or similar
|
||||
- `app/api/reports/**` — report endpoints
|
||||
- `app/reports/**` — report UI
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- `lib/reports/trial-balance.ts`, `lib/reports/general-ledger.ts` — base reports
|
||||
- `app/bookkeeping/year-end/**` — likely triggers årsredovisning generation
|
||||
- `types/index.ts` — report types
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **K2 vs K3 uppställningsform**:
|
||||
- K2: simplified balance sheet + income statement, fewer noter
|
||||
- K3: full BFNAR 2012:1, more granular, komponentavskrivning mandatory for larger assets, segment reporting possible
|
||||
- Is the K2/K3 choice persisted per company? Does the report structure actually differ between them?
|
||||
- **Required noter**:
|
||||
- K2 minimum: redovisningsprinciper, anläggningstillgångar (ingående anskaffningsvärde, årets anskaffningar, årets avskrivningar, utgående), lönekostnader per kategori
|
||||
- K3 adds: kassaflödesanalys, sekundära noter per post
|
||||
- Are required noter generated? If not, that's a hole in the report.
|
||||
- **Förvaltningsberättelse**: required content per ÅRL 6 kap — verksamhetsbeskrivning, väsentliga händelser under året, forward-looking statements, förändring av eget kapital, förslag till resultatdisposition. Is this a template the user fills in, or is some of it auto-filled from data?
|
||||
- **Underskrifter**: all styrelseledamöter must sign. Is the UI set up to handle this (signature page, multiple signers)?
|
||||
- **Kassaflödesanalys**: mandatory in K3, optional in K2. Computed correctly from balance changes?
|
||||
- **Bolagsverket filing deadlines**:
|
||||
- AB: årsstämma within 6 months of fiscal year end; årsredovisning filed within 1 month of stämma = 7 months total after year-end
|
||||
- Late filing → förseningsavgift 5000 SEK (first), 10000 SEK (second), 25000 SEK (third after 1+ month)
|
||||
- >11 months late → tvångslikvidation risk
|
||||
- Are deadlines computed and shown? Warning escalation?
|
||||
- **iXBRL**: Bolagsverket requires iXBRL for digital submission (since 2024 mandatory for certain sizes). Any generator? Probably not — that's a gap.
|
||||
- **Revisionsplikt**: company must have auditor if meets 2 of 3: >3 employees avg, >1.5M SEK balance, >3M SEK revenue. Is this checked/tracked?
|
||||
- **INK2 form logic**:
|
||||
- INK2 (main): bolagsskatt calculation
|
||||
- INK2R (räkenskapsschema): BAS-aligned P&L and BS
|
||||
- INK2S (skattemässiga justeringar): periodiseringsfond, överavskrivningar, koncernbidrag, ej avdragsgilla kostnader
|
||||
- Field mappings correct? "Vilka noter krävs" / "hur fyller jag i INK2" answerable from code?
|
||||
- **N9 (interest deduction limits)**: EBITDA rule, applicable if net interest > 5M SEK. Is there any handling?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: årsredovisning produces wrong belopp (e.g., wrong total assets, wrong årets resultat); missing mandatory note; wrong K2 vs K3 applied
|
||||
- **high**: noter incomplete; förvaltningsberättelse template missing; signature flow missing
|
||||
- **medium**: iXBRL missing (gap); revisionsplikt not tracked; missing forward-looking statement prompt
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-financial-reporting-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-financial-reporting-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite ÅRL chapter or BFNAR}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required on every finding.
|
||||
- Stay in your lane. Year-end *mechanics* → `swarm-year-end-agent`. SRU file generation → `swarm-sru-agent`. You focus on report *structure* and filing compliance.
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
name: swarm-invoice-compliance-agent
|
||||
description: "Read-only audit agent for Swedish invoice compliance (ML 17 kap 24§). Sweeps gnubok for mandatory invoice field correctness, kreditfaktura handling, reverse charge notation, ROT/RUT fakturamodellen, Peppol e-invoicing, OCR/Bankgirot, currency invoice rules. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-invoice-compliance-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish invoice compliance (fakturering)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-invoice-compliance` skill via the Skill tool. Treat its knowledge as the compliance baseline. ML 2023:200 replaced ML 1994:200 on 2023-07-01 — invoice rules moved from old Chapter 11 to Chapter 17.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/invoices/` — invoice engine, reminders, payment matching, VAT rules, PDF template
|
||||
- `app/invoices/**` — invoice pages (new, edit, credit, list)
|
||||
- `app/api/invoices/**` — invoice CRUD, send, mark-sent/paid, PDF, reminders
|
||||
- `lib/bookkeeping/invoice-entries.ts` — journal entry generation from invoices
|
||||
- `components/invoices/**` (if exists) — invoice form UI
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- `lib/invoices/pdf-*.ts` or invoice PDF template — rendered invoice fields
|
||||
- `types/index.ts` — Invoice, InvoiceItem, InvoicePayment types
|
||||
- `app/api/supplier-invoices/**` — incoming invoice validation (some same rules apply)
|
||||
- `lib/bookkeeping/bas-data/**` — accounts 1510, 3001/3002/3003, 3305/3308, 3740 (ROT/RUT)
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Mandatory invoice fields (ML 17 kap 24§)**: issue date, unique sequential invoice number, seller org number + VAT number, buyer name+address, quantity + description, net amount per rate, VAT amount per rate, total, VAT rate per line — is every mandatory field present and enforced?
|
||||
- **Förenklad faktura**: conditions (≤4000 SEK incl. VAT), required fields reduced — is the simplified version available when applicable?
|
||||
- **Kreditfaktura / ändringsfaktura**: must reference original invoice number, must reverse original amounts — is this enforced? Do credit notes use negative amounts correctly?
|
||||
- **Självfakturering**: if supported, is there an agreement field? Is "Självfakturering" / "Self-billing" printed on the invoice?
|
||||
- **Reverse charge notation**: specific Swedish text required per scenario — "Omvänd betalningsskyldighet för byggtjänster", "Reverse charge — Article 196", "Omvänd betalningsskyldighet — handel inom EU". Is the right text printed?
|
||||
- **Peppol BIS 3.0 e-faktura**: any handling at all? Flag missing if customer expects e-invoicing (common for B2G).
|
||||
- **ROT/RUT fakturamodellen**: BAS 1513 (fordran Skatteverket), BAS 3740 (ROT/RUT-reduction), right amount calculation (labor portion only, cap rules)?
|
||||
- **OCR/Bankgirot**: Luhn checksum validated? Is `lib/bankgiro/` actually used end-to-end?
|
||||
- **Autogiro**: any handling?
|
||||
- **Currency invoice**: if invoice in EUR/USD, are SEK amounts computed on invoice date, is VAT shown in both currencies?
|
||||
- **Skattetillägg / förseningsavgift**: handling of late-payment interest (räntelagen 8%) — wired up?
|
||||
- **Bad debts (osäkra fordringar)**: BAS 1515/1519/6352 — is write-off path present?
|
||||
- **Reminder logic** (`app/api/invoices/reminders/cron`): does it send in Swedish? Correctly track reminder count? Respect reminder schedule?
|
||||
- **Public invoice action link** (`app/invoice-action/[token]`): token entropy, expiry, what if token leaks?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: mandatory ML 17 kap 24§ field missing on printed invoice, kreditfaktura reverses incorrectly, invoice number non-sequential or gap-prone
|
||||
- **high**: reverse charge text wrong/missing, ROT/RUT calculation wrong, Swedish user-facing message wrong
|
||||
- **medium**: missing validation on non-critical fields, unclear error, missing test for known edge case
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-invoice-compliance-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-invoice-compliance-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite ML 17 kap section where relevant}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings. Always write the report.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required on every finding.
|
||||
- Stay in your lane. VAT calculation correctness belongs to `swarm-vat-agent`. You focus on invoice field correctness, not VAT math.
|
||||
@@ -1,166 +0,0 @@
|
||||
---
|
||||
name: swarm-logging-agent
|
||||
description: "Read-only audit agent for gnubok's structured logging (lib/logger.ts). Sweeps for console.log usage instead of structured logger, missing module prefixes, missing context on errors, sensitive data in logs (PII, tokens, bank numbers), log level correctness (info vs warn vs error), noisy verbose logging in production, absent logging in critical paths. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-logging-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **structured logging and observability**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Baseline
|
||||
|
||||
gnubok has a structured logger at `lib/logger.ts` with module prefixes and env-aware filtering. Every log line should flow through it — not `console.log`.
|
||||
|
||||
Levels: `debug`, `info`, `warn`, `error` (plus `fatal` if supported).
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `lib/logger.ts` — logger definition itself
|
||||
- `lib/**`, `app/**`, `extensions/**`, `middleware.ts` — all code that logs
|
||||
- `components/**` — client-side logging (less common, but check)
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### `console.log` / `console.error` / `console.warn` usage
|
||||
- **Goal**: zero `console.*` in production code (unless inside logger itself)
|
||||
- Flag every `console.log(` in `lib/`, `app/`, `extensions/`
|
||||
- Exception: logger internals, test files, scripts in `scripts/`
|
||||
|
||||
### Structured logging
|
||||
- Every log line should include:
|
||||
- Module prefix (e.g., `[bookkeeping-engine]`, `[vies-client]`)
|
||||
- Level (debug/info/warn/error)
|
||||
- Message (short, descriptive)
|
||||
- Context object (key-value data relevant to the event)
|
||||
- Flag logs that are just strings without context
|
||||
|
||||
### Context completeness
|
||||
- Errors should include: error message, stack (for debug level), relevant IDs (company_id, user_id, entry_id), operation being attempted
|
||||
- Logs without `companyId` in a company-scoped operation are hard to debug
|
||||
- Logs without request ID / correlation ID are hard to trace across services
|
||||
|
||||
### Sensitive data redaction
|
||||
- **Never log**:
|
||||
- Raw passwords
|
||||
- API keys / bearer tokens
|
||||
- Personal identity numbers (personnummer)
|
||||
- Bank account numbers (bankgiro, IBAN)
|
||||
- Session cookies / JWTs
|
||||
- Credit card data (shouldn't exist in gnubok)
|
||||
- OAuth codes, code_verifier
|
||||
- MFA TOTP secrets
|
||||
- Flag any log line that interpolates a secret or identifier without masking
|
||||
- Error serializers that include `req.headers.authorization` — flag
|
||||
|
||||
### Log level correctness
|
||||
- `debug`: dev-only, verbose, step-by-step
|
||||
- `info`: production, notable operations (entry committed, invoice sent), low frequency
|
||||
- `warn`: something unexpected but recovered (retrying, fallback taken, degraded mode)
|
||||
- `error`: operation failed, user saw an error, requires attention
|
||||
- Flag: error-level for routine events, info for actual errors, noise at info in prod
|
||||
|
||||
### Noise at info level
|
||||
- `info` should be actionable — something ops or a developer cares about after the fact
|
||||
- Chatty "processing transaction 1 of 50... processing transaction 2 of 50..." is `debug`, not `info`
|
||||
- User-facing clicks, route navigations, form opens — not logged
|
||||
|
||||
### Missing logs in critical paths
|
||||
- **Always log** at info+ level:
|
||||
- Journal entry committed (with voucher number)
|
||||
- Invoice sent (with recipient, invoice #)
|
||||
- Bank sync started/completed
|
||||
- Login success/failure
|
||||
- MFA enrolled/verified/failed
|
||||
- API key created/revoked
|
||||
- Company created/deleted
|
||||
- Extension enabled/disabled
|
||||
- Flag where these events are silent
|
||||
|
||||
### Error logging in catch blocks
|
||||
- Every non-trivial catch should log the error at appropriate level
|
||||
- `catch (e) { console.error(e) }` → should be `logger.error({ err: e, context: {...} }, "operation failed")`
|
||||
- Stack traces belong in error logs (debug-level stack if error log doesn't include it)
|
||||
|
||||
### Structured error serialization
|
||||
- Errors should be serialized consistently: name, message, code, stack
|
||||
- Avoid `.toString()` on complex errors (loses context)
|
||||
- Avoid `JSON.stringify(err)` (Error doesn't serialize well by default)
|
||||
|
||||
### Async / unhandled rejections
|
||||
- Top-level `unhandledRejection` handler? Sentry handles if configured.
|
||||
- Every `.then(...)` that could throw has a `.catch(logger.error, ...)` downstream?
|
||||
|
||||
### Client-side logging
|
||||
- Browser `console.log` on UI components — generally not needed
|
||||
- If client logs are sent to Sentry: is PII stripped?
|
||||
- Error boundaries log via `logger.error` (bridging to server if needed) or via Sentry?
|
||||
|
||||
### Log aggregation & retention
|
||||
- Logs are where — stdout (for Vercel), Supabase logs, Sentry?
|
||||
- Structured format (JSON) preferred for log aggregators
|
||||
- Retention: Vercel keeps logs; Sentry has its own retention
|
||||
- Is there log correlation between frontend error and backend error? (Request IDs help)
|
||||
|
||||
### Cron logging
|
||||
- Every cron run: start, success/failure, duration, items processed
|
||||
- Easy audit from logs: "did the invoice reminders cron run yesterday?"
|
||||
|
||||
### Provider call logging
|
||||
- VIES call: log request (VAT number), response status, duration
|
||||
- Enable Banking sync: items pulled, duration, errors
|
||||
- AI calls: model, token usage, latency, redacted prompt
|
||||
- Flag missing observability on provider calls
|
||||
|
||||
### Audit log vs application log
|
||||
- `audit_log` table = compliance record (tamper-proof, immutable)
|
||||
- Application logs = debugging, operational
|
||||
- Don't conflate: audit-worthy events should go to `audit_log`, not just stdout
|
||||
- Don't duplicate massively (audit log isn't for debug traces)
|
||||
|
||||
### Sentry integration
|
||||
- Errors captured via Sentry if DSN configured
|
||||
- User context attached (user ID, company ID) — without PII
|
||||
- Breadcrumbs enabled for context
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: personnummer / API key / bankgiro number logged; sensitive data in Sentry breadcrumbs
|
||||
- **high**: catch block swallows error without logging; missing log on critical path (entry commit, invoice send)
|
||||
- **medium**: `console.log` in production code; wrong log level; missing context object
|
||||
- **low**: chatty info-level logs; missing module prefix; inconsistent format
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-logging-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-logging-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Aspect**: console-use | level | context | redaction | missing | noise | structure
|
||||
- **Description**: {what's wrong, impact on debugging/compliance}
|
||||
- **Suggested fix**: {what should change — usually a concrete logger call}
|
||||
```
|
||||
|
||||
Add **Aspect** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Stay in your lane. Error handling UX (Swedish user messages) → `swarm-error-handling-agent`. You own server-side observability.
|
||||
@@ -1,159 +0,0 @@
|
||||
---
|
||||
name: swarm-mobile-ux-agent
|
||||
description: "Read-only audit agent for gnubok's mobile UX. Sweeps for touch targets (≥44×44pt), safe areas (notch, home indicator), responsive breakpoints, mobile navigation patterns (bottom tabs vs hamburger), input modes (numeric/decimal keyboards for amounts), orientation handling, viewport meta, pull-to-refresh, gesture friction. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-mobile-ux-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **mobile UX quality**. gnubok users often check invoices, categorize transactions, or send a reminder from their phone between meetings. The mobile experience needs to work. You never write code, never create tickets, never commit.
|
||||
|
||||
## Baseline
|
||||
|
||||
Use the `mobile-ux-core` skill via the Skill tool for universal mobile principles. Layer gnubok-specific concerns on top.
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `app/**/*.tsx`, `app/**/*.jsx` — pages, layouts (responsive classes `sm:` / `md:` / `lg:`)
|
||||
- `components/**/*.tsx` — reusable UI, especially nav, modals, forms, tables
|
||||
- `app/layout.tsx` — `<meta name="viewport">` configuration
|
||||
- `app/globals.css` — safe area CSS variables, touch styles
|
||||
- `tailwind.config.*` — breakpoint customizations
|
||||
- Any `useIsMobile` hook or similar
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`, `app/api/**`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Viewport meta
|
||||
- `<meta name="viewport" content="width=device-width, initial-scale=1">` present
|
||||
- Avoid `maximum-scale=1` or `user-scalable=no` (breaks zoom for low-vision users)
|
||||
|
||||
### Touch targets (WCAG AA + Apple HIG)
|
||||
- Minimum 44×44 CSS pixels (equivalent to 44pt on iOS, ~7mm physical)
|
||||
- Check icon-only buttons, nav items, table row actions, toggle switches
|
||||
- Density check: two touch targets ≥ 8px apart (prevents fat-finger mis-taps)
|
||||
- Common offender: checkboxes in dense tables — the checkbox itself may be 16×16 but the clickable area must extend
|
||||
|
||||
### Safe areas
|
||||
- iOS notch, Dynamic Island, home indicator
|
||||
- CSS: `env(safe-area-inset-top/bottom/left/right)` used on sticky elements
|
||||
- Bottom-docked elements (nav bar, toast, cta) padded with `env(safe-area-inset-bottom)`
|
||||
- Top-docked elements (header) padded with `env(safe-area-inset-top)`
|
||||
- Full-bleed backgrounds extend into safe area but content doesn't
|
||||
|
||||
### Responsive breakpoints
|
||||
- Tailwind defaults: `sm:640px`, `md:768px`, `lg:1024px`, `xl:1280px`, `2xl:1536px`
|
||||
- Mobile-first: base styles are mobile; `sm:`/`md:` scale up
|
||||
- Sidebar that hides on mobile — is there an alternative (bottom sheet, drawer)?
|
||||
- Table that doesn't fit on mobile — scrollable, stacks, or transforms?
|
||||
|
||||
### Mobile navigation
|
||||
- Desktop sidebar on mobile: must collapse to hamburger or bottom tabs
|
||||
- Bottom tab bar for primary nav (modern pattern): 3-5 items, sticky, safe-area padded
|
||||
- Hamburger menu: accessible (keyboard, screen reader)
|
||||
- Current-page indicator clear
|
||||
- Nav doesn't obscure content (especially when a soft keyboard opens)
|
||||
|
||||
### Input modes for mobile keyboards
|
||||
- Amount inputs: `inputMode="decimal"` (shows decimal keypad)
|
||||
- Integer inputs: `inputMode="numeric"`
|
||||
- Phone: `inputMode="tel"` + `type="tel"`
|
||||
- Email: `type="email"` (triggers `@` key)
|
||||
- Search: `type="search"` (triggers search button)
|
||||
- Swedish invoice: OCR numbers expect digits only — `inputMode="numeric"`
|
||||
- Date pickers: prefer `type="date"` on mobile (native picker)
|
||||
|
||||
### Form UX on mobile
|
||||
- Long forms: one column (not side-by-side fields that wrap awkwardly)
|
||||
- Labels above fields, not beside
|
||||
- Submit button full-width on mobile
|
||||
- Autofocus on first field? (Some apps do, some don't — consistency matters)
|
||||
- Inline errors visible without keyboard dismissal
|
||||
- Don't reset the form on validation error (preserve input)
|
||||
|
||||
### Tables on mobile
|
||||
- Full table on mobile: bad UX (horizontal scroll, tiny text)
|
||||
- Better: transform to card list (each row → card with key fields)
|
||||
- Or: show core columns on mobile, expand-on-tap for details
|
||||
- Or: persistent horizontal scroll with sticky first column
|
||||
|
||||
### Modals & dialogs
|
||||
- Full-screen on mobile (not centered windowed)
|
||||
- Sticky header + action buttons
|
||||
- Dismiss via swipe down (nice-to-have) or clear X button
|
||||
- Avoid stacked modals on mobile
|
||||
|
||||
### Scroll behavior
|
||||
- Pull-to-refresh: supported on list pages? (browser default often works)
|
||||
- Infinite scroll vs pagination: either, but not both confusingly
|
||||
- Sticky table headers on long tables
|
||||
- Scroll position preserved when navigating back
|
||||
|
||||
### Gesture support
|
||||
- Swipe to delete (email-app style) on list rows? Optional but slick
|
||||
- Long-press for context menu on tables?
|
||||
- Pinch-to-zoom on charts/PDFs?
|
||||
|
||||
### Orientation
|
||||
- Landscape: does it work? (Many form pages are portrait-optimized)
|
||||
- Lock orientation never (accessibility)
|
||||
|
||||
### Performance on mobile
|
||||
- Hero images / large lists — not blocking mobile render
|
||||
- JS bundle size — overlap with performance agent
|
||||
- Lazy-load below-the-fold images
|
||||
|
||||
### PWA / home screen
|
||||
- Manifest present? Favicon/apple-touch-icon?
|
||||
- Installable as PWA? (Nice-to-have for frequent users)
|
||||
|
||||
### Swedish decimal/thousands on mobile
|
||||
- Decimal keyboard shows comma or period depending on locale — gnubok accepts both?
|
||||
|
||||
### Specific gnubok flows to audit
|
||||
- **Invoice creation**: all fields accessible, amount input with decimal keyboard, customer picker usable on mobile
|
||||
- **Transaction categorization**: quick swipe/tap-to-categorize?
|
||||
- **Receipt scan** (when extension enabled): camera access, crop UI
|
||||
- **Approval flows**: approve supplier invoice, confirm journal entry — one-tap clarity
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: core flow (invoice creation, transaction categorization) broken on mobile
|
||||
- **high**: touch target < 44×44; nav unreachable on mobile; form input wrong keyboard
|
||||
- **medium**: safe area ignored; modal not full-screen on mobile; table horizontal-scroll without indication
|
||||
- **low**: orientation bug in rare screen; missing pull-to-refresh
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-mobile-ux-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-mobile-ux-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.tsx:123`
|
||||
- **Surface**: nav | form | table | modal | safe-area | input | gesture | viewport
|
||||
- **Description**: {what's wrong on mobile specifically}
|
||||
- **Suggested fix**: {what should change — cite specific Tailwind class or CSS property}
|
||||
```
|
||||
|
||||
Add **Surface** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Check `sm:` / `md:` responsive classes carefully — easy to forget mobile-first defaults
|
||||
- Stay in your lane. Visual consistency → `swarm-ui-ux-agent`. Accessibility details → `swarm-a11y-agent` (44×44 overlap is fine).
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
name: swarm-payroll-agent
|
||||
description: "Read-only audit agent for Swedish payroll (lön, arbetsgivaravgifter, AGI). Sweeps gnubok for skatteavdrag correctness, sociala avgifter calculation, AGI filing, förmånsbeskattning, semesterlöneskuld, OB-tillägg, traktamente, sjuklön/karensavdrag, F-skatt verification, BAS 7xxx account mapping. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-payroll-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish payroll (lön & arbetsgivaravgifter)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-payroll` skill via the Skill tool. Treat it as the compliance baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/salary/**` (if exists) — salary engine, tax calculations, benefits
|
||||
- `app/api/salary/**` (if exists) — salary payment CRUD, AGI submission
|
||||
- `app/salary/**` or equivalent UI
|
||||
- `lib/bookkeeping/bas-data/**` — accounts 7010-7699 (wages), 7510 (avgifter), 7321-7332 (traktamente/resor), 2710-2730 (skatt, avgifter)
|
||||
- Database table: `salary_payments`
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- Any journal entry generator that touches 7xxx accounts
|
||||
- `types/index.ts` — salary/payroll types
|
||||
- Tax code definitions, deadline generator (AGI due dates)
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
**Note**: The CLAUDE.md memory references a "Salary Module Phase 4 plan". If any Phase 4 features are not yet implemented (bank matching, corrections, email, AGI submission, KU10, tax tables import, F-skatt warning), note these as gaps in your findings — but frame them as medium severity, not critical, since they are tracked work.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Skatteavdrag (tax withholding)**: correct tax table lookup (skattetabell 29-36), column system (kolumn 1-6), jämkning handling, preliminär skatt vs slutlig skatt
|
||||
- **Sociala avgifter 31.42%**: correct total and per-component breakdown (ålderspension 10.21%, efterlevande 0.60%, sjukförsäkring 3.55%, etc.), age reductions (born ≥ 1938 but ≤ 65, youth)
|
||||
- **AGI (arbetsgivardeklaration)**: monthly deadline handling, individual-level reporting (IU), correct field mapping, penalty for late filing
|
||||
- **Förmånsbeskattning**: bilförmån calculation (correct 2026 rates, nybilspris lookup), kostförmån (2026 rate), friskvårdsbidrag cap (5000 SEK), KPO
|
||||
- **Semesterlöneskuld**: procentregeln 12% on lönegrund, sammalöneregeln alternative, BAS 2920 (skuld) + 7090 (kostnad) correctly paired
|
||||
- **OB-tillägg / övertid**: arbetstidslagen limits (max 200h övertid/år), CBA divisors, is any of this enforced?
|
||||
- **Traktamente**: domestic/international rates, tremånadersregeln (reduction after 3 months), meal reductions (frukost/lunch/middag percentages), BAS 7321 (tax-free) vs 7322 (taxable portion)
|
||||
- **Milersättning**: 2026 rate for egen bil, körjournal requirement, BAS 7331/7332 split
|
||||
- **F-skatt vs A-skatt**: is the distinction enforced? Verification against Skatteverket? A consultant with F-skatt should not get skatteavdrag
|
||||
- **Sjuklön**: karensavdrag (20% of average weekly pay, not one day), day 2-14 at 80%, handoff to Försäkringskassan day 15+
|
||||
- **Löneväxling**: factor 1.058 on pension contribution, age-based pension cap (35% of gross up to 7.5 IBB)
|
||||
- **Nettolöneavdrag vs bruttolöneavdrag**: processing order matters — brutto reduces skatteunderlag, netto does not
|
||||
- **Error handling**: payroll errors are critical — are they in Swedish, specific, and do they prevent partial AGI submission?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: wrong skatteavdrag booked, wrong avgifter calculation, AGI submission with wrong figures, förmån missed
|
||||
- **high**: wrong semesterlöneskuld, OB-tillägg miscalculated, sjuklön karensavdrag wrong
|
||||
- **medium**: missing feature vs Phase 4 plan (bank matching, KU10), unclear error message
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-payroll-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-payroll-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings (or feature area not yet built): `## Summary\nPayroll module is partial or missing — see Phase 4 plan` plus findings for gaps, or `No findings` if everything looks good.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required on every finding.
|
||||
- Stay in your lane. General VAT and booking engine concerns belong to other agents.
|
||||
@@ -1,160 +0,0 @@
|
||||
---
|
||||
name: swarm-performance-agent
|
||||
description: "Read-only audit agent for gnubok's performance. Sweeps for bundle size bloat, N+1 query patterns, missing DB indexes, unnecessary re-renders, blocking imports, large image assets, unoptimized list rendering, fetchAllRows misuse, synchronous heavy work on the main thread. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-performance-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **performance** — perceived latency, bundle size, DB query efficiency, render efficiency. gnubok targets the 90-second session: every tick of delay is friction. You never write code, never create tickets, never commit.
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `app/**/*.tsx`, `app/**/*.jsx` — pages, layouts, components
|
||||
- `components/**/*.tsx` — UI components
|
||||
- `lib/**/*.ts` — business logic (DB queries, heavy computations)
|
||||
- `app/api/**/*.ts` — API routes (query patterns)
|
||||
- `next.config.*` — build config
|
||||
- `package.json` — dependencies (watch for heavy ones)
|
||||
- `supabase/migrations/**` — indexes, RLS complexity
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Bundle size
|
||||
- Heavy dependencies in the client bundle: date-fns (use only needed functions), moment (should be dayjs or native), lodash (use per-function imports or native)
|
||||
- Client-side AI SDKs (Anthropic, OpenAI) — should be server-only
|
||||
- Chart libraries: Recharts is OK, Chart.js is heavy. Lightweight preferred for the few charts in gnubok
|
||||
- Framer Motion: fine if used, but on every page? May be overkill
|
||||
- Audit `import` paths in client components (`'use client'`) — anything huge imported unnecessarily?
|
||||
|
||||
### Server/client boundary
|
||||
- `'use client'` on large trees — flag. Prefer server components for static content, client only for interactive
|
||||
- Server components can import heavy libs (they don't bundle to client)
|
||||
- Data fetching: `async` server components with `await supabase.from(...)` — no client-side fetch for initial data needed
|
||||
|
||||
### Next.js specifics
|
||||
- `Image` component used for images (not bare `<img>`)
|
||||
- `dynamic()` imports for heavy client components (charts, PDF viewers)
|
||||
- `loading.tsx` for perceived fast loads
|
||||
- Streaming responses (`<Suspense>` boundaries) for long-running data
|
||||
|
||||
### DB query patterns — N+1
|
||||
- Fetching a list then looping to fetch related — flag
|
||||
- Prefer Supabase joins: `.select('*, items(*)')` over separate queries
|
||||
- For many-to-many: `select` with join notation
|
||||
- In server components: avoid mid-render queries; fetch at page level
|
||||
|
||||
### Pagination
|
||||
- `fetchAllRows()` (from `lib/supabase/fetch-all.ts`) — useful but dangerous
|
||||
- Is it capped at a reasonable max (e.g., 10k rows)?
|
||||
- Is it used on paths that could return millions of rows (large fiscal years, bank transaction history)?
|
||||
- Prefer proper pagination (range, cursor) for user-facing lists
|
||||
|
||||
### Missing indexes
|
||||
- For each frequently-queried table, is there an index on query columns?
|
||||
- Migrations: indexes on `company_id`, `created_at`, sometimes composite (`(company_id, fiscal_period_id)`)
|
||||
- WHERE clauses on non-indexed columns with large tables → slow
|
||||
- Check reports: general ledger, trial balance, VAT declaration — range queries on `created_at`/`transaction_date` need indexes
|
||||
|
||||
### RLS performance
|
||||
- RLS policies calling functions: `user_company_ids()` is function-based. Is it stable/immutable-tagged? Indexed on `company_id`?
|
||||
- Complex policies with joins: can be slow on large tables
|
||||
- Use `EXPLAIN ANALYZE` (in dev) to check
|
||||
|
||||
### React render performance
|
||||
- `useMemo`/`useCallback` — overuse is worse than underuse, but in hot paths (tables with 1000+ rows) useful
|
||||
- Inline functions as props to memoized children — breaks memoization
|
||||
- `key` on list items: stable, unique (not array index in reorderable lists)
|
||||
- Huge list without virtualization: flag (use `@tanstack/react-virtual` or similar)
|
||||
|
||||
### Expensive operations on main thread
|
||||
- Large JSON parse/stringify in the browser
|
||||
- Sync cryptography (hashing, signing) — prefer async `SubtleCrypto`
|
||||
- CSV/SIE parsing of huge files in the browser without Web Workers
|
||||
|
||||
### Image optimization
|
||||
- Invoice PDF rendering: server-side, not client-side?
|
||||
- Uploaded receipts: processed via `sharp` on the server to reasonable size?
|
||||
- Avatars / logos: served at small sizes, not full resolution
|
||||
|
||||
### Animation performance
|
||||
- CSS transforms (`transform`, `opacity`) — GPU-accelerated, fast
|
||||
- `top`/`left`/`width`/`height` — layout-triggering, slow
|
||||
- Framer Motion: prefer `transform`-based animations
|
||||
|
||||
### Caching
|
||||
- React Server Component caching (default behavior): any `dynamic = 'force-dynamic'` on pages that could be cached?
|
||||
- `fetch()` options: `next: { revalidate: ... }` where appropriate
|
||||
- Provider calls (VIES, Riksbanken): cached? For how long?
|
||||
- Short-lived caches vs DB-backed (e.g., exchange rates table)
|
||||
|
||||
### Cold start vs warm
|
||||
- Vercel serverless: cold start on infrequent routes
|
||||
- Heavy module-level code runs on cold start — `ensureInitialized()` is minimal? Or loads everything?
|
||||
- Supabase client creation per request vs reused — per request is correct here (cookies), but each create should be light
|
||||
|
||||
### Asset loading
|
||||
- Fonts: subset if possible; `font-display: swap`
|
||||
- CSS: Tailwind purged to only used classes
|
||||
- Fresh JS bundle per route when it should share common chunks
|
||||
|
||||
### Lazy loading
|
||||
- Admin/settings pages behind dynamic imports — reduce initial bundle
|
||||
- Heavy extensions UI loaded only when opened
|
||||
|
||||
### Waterfall fetches
|
||||
- Sequential `await` where parallel would work: flag with `Promise.all` suggestion
|
||||
- A page fetching user → company → settings → data sequentially — can parallelize
|
||||
|
||||
### Lighthouse / Web Vitals (guess from code)
|
||||
- LCP: largest contentful paint — usually the first image or hero text. Any render-blocking above-the-fold thing?
|
||||
- CLS: layout shift — reserve space for images/ads; avoid web fonts that FOIT/FOUT
|
||||
- TBT: total blocking time — heavy JS work on mount
|
||||
|
||||
### Specific gnubok hot paths
|
||||
- Dashboard home — should be fast (first page after login)
|
||||
- Transactions list — often thousands of rows, needs virtualization or pagination
|
||||
- Reports (general ledger, trial balance) — potentially huge, needs streaming/chunking
|
||||
- Full archive export — necessarily slow, but should stream, not materialize in memory
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: page loads >5s on p75 (inferred from code patterns like sync large operations, unvirtualized big lists)
|
||||
- **high**: N+1 query in hot path; `fetchAllRows` unbounded on large table; missing index on frequently-queried column
|
||||
- **medium**: heavy client dependency; unnecessary `'use client'` on large tree; bundle bloat
|
||||
- **low**: missing `useMemo` in non-hot path; uncompressed image; minor CSS performance
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-performance-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-performance-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123` or migration file
|
||||
- **Aspect**: bundle | query | render | index | caching | waterfall | pagination | asset
|
||||
- **Description**: {what's slow or wasteful, estimated impact}
|
||||
- **Suggested fix**: {what should change, concrete}
|
||||
```
|
||||
|
||||
Add **Aspect** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only. Do not run benchmarks or profiling — you're static-analyzing.
|
||||
- File:line required.
|
||||
- Stay in your lane. Rate limits → `swarm-rate-limits-agent`. Test coverage → `swarm-testing-agent`. You own speed/efficiency.
|
||||
@@ -1,94 +0,0 @@
|
||||
---
|
||||
name: swarm-project-accounting-agent
|
||||
description: "Read-only audit agent for Swedish project accounting (projektredovisning). Sweeps gnubok for dimensional tagging of bokföringsposter with project codes, WIP accounting (pågående arbeten), revenue recognition under K2/K3, construction contracts, BAS account patterns for project tracking, SIE4 dimension encoding. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-project-accounting-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish project accounting (projektredovisning)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-project-accounting` skill via the Skill tool. Treat it as the baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- Database tables: `cost_centers`, `projects`
|
||||
- `types/index.ts` — Project, CostCenter types
|
||||
- Migration files establishing these tables
|
||||
- Journal entry lines — `journal_entry_lines.project_id` / `cost_center_id` columns
|
||||
- `lib/bookkeeping/**` engine code — does it propagate project_id / cost_center_id?
|
||||
- `lib/reports/**` — any project-filtered reports?
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- SIE import/export — `#DIM 6,Projekt` / `#DIM 1,Kostnadsställe` / `#OBJEKT` records
|
||||
- UI: any project picker in invoice/expense/journal-entry forms?
|
||||
- `app/api/projects/**` (if exists)
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
**Note**: If gnubok has no project accounting at all, that's a *gap* for consultants and construction companies — medium severity, not critical, since it's a feature-level miss not a compliance fault.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Dimensional tagging**: do journal entry lines support `project_id` and `cost_center_id`? Is it enforced on write for project-tracked companies?
|
||||
- **WIP accounting (pågående arbeten)**:
|
||||
- BAS 1470: pågående arbeten för annans räkning (WIP asset)
|
||||
- BAS 1620: upparbetad men ej fakturerad intäkt
|
||||
- BAS 2420: förskott från kund
|
||||
- BAS 2450: fakturerad men ej upparbetad intäkt
|
||||
- BAS 4970: årets förändring av pågående arbeten
|
||||
- Any of these wired up?
|
||||
- **Revenue recognition**:
|
||||
- K2: färdigställandemetoden only (book revenue when job is done)
|
||||
- K3: successiv vinstavräkning allowed (% of completion) — requires reliable cost estimate + completion measurement
|
||||
- Entreprenadavtal (construction contracts) — special rules
|
||||
- Does the code enforce K2 vs K3 choice?
|
||||
- **Cost center vs project distinction**:
|
||||
- Kostnadsställe (BAS #DIM 1): internal org unit (e.g., department)
|
||||
- Projekt (BAS #DIM 6): external project
|
||||
- Are both supported, and distinguished properly?
|
||||
- **SIE4 dimension encoding**: `#DIM 6,Projekt` followed by `#OBJEKT 6,P100,"Webbplats kund X"` — correctly parsed on import and generated on export?
|
||||
- **Project-filtered reports**: can the user run a trial balance / income statement filtered by project_id? Essential for consultants.
|
||||
- **Project budget vs actual**: any budget tracking? (Common need but may be out of scope.)
|
||||
- **Hour tracking integration**: timesheet → journal entry with project tag? Gnubok likely doesn't have timesheets yet.
|
||||
- **Construction contract specifics**: retention (innehållen del), färdigställandegrad measurement, loss-making contracts (must provision immediately under K3).
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: project accounting silently drops dimension on journal entries; WIP booked to wrong account class
|
||||
- **high**: K2 company allows successiv vinstavräkning (illegal); SIE dimension round-trip broken
|
||||
- **medium**: no project-filtered reports; no WIP support at all for construction companies; cost center vs project conflation
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-project-accounting-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-project-accounting-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite BFNAR or BAS where relevant}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings. If feature entirely missing, that IS the finding (medium severity).
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Stay in your lane. SIE4 correctness broadly → `swarm-sie-agent`; you focus on the dimension/project angle of it.
|
||||
@@ -1,137 +0,0 @@
|
||||
---
|
||||
name: swarm-provider-connections-agent
|
||||
description: "Read-only audit agent for gnubok's external provider integrations (Enable Banking PSD2, TIC Identity, Skatteverket, Resend email, Anthropic, OpenAI, Supabase, VIES). Sweeps for timeout handling, retry logic, circuit breaking, secret management, failure UX (do users see clear Swedish messages when provider X is down?), token refresh, rate-limit awareness. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-provider-connections-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **external provider integrations**. Every time gnubok calls out over the network, you evaluate: does it time out correctly? Does it retry with backoff? What happens when the provider is down? Does the user see a clear Swedish message or a generic "Something went wrong"?
|
||||
|
||||
You never write code, never create tickets, never commit.
|
||||
|
||||
## Providers in scope
|
||||
|
||||
| Provider | Purpose | Where |
|
||||
|---|---|---|
|
||||
| **Enable Banking** | PSD2 bank sync | `extensions/general/enable-banking/**` |
|
||||
| **TIC Identity** | Org number → company lookup | `extensions/general/tic/**` |
|
||||
| **Skatteverket** | VAT declaration submission (future) | `extensions/general/skatteverket/**`, `lib/skatteverket/**` |
|
||||
| **Resend** | Transactional email | `extensions/general/email/**`, `lib/email/**` |
|
||||
| **Anthropic** | AI features (chat, categorization, receipts) | AI extensions, `lib/transactions/**` suggestions |
|
||||
| **OpenAI** | Embeddings | same AI surfaces |
|
||||
| **Supabase** | Core DB, auth, storage | Across the app (see `lib/supabase/**`) |
|
||||
| **VIES** | EU VAT number validation | `lib/vat/vies-client.ts` |
|
||||
| **Riksbanken** | Exchange rates | `lib/currency/**` |
|
||||
| **Svix** | Webhooks | search for `svix` |
|
||||
| **web-push** | Browser push | `extensions/general/push-notifications/**` (disabled) |
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `extensions/general/*/api/**` — extension HTTP handlers calling providers
|
||||
- `lib/vat/vies-client.ts`
|
||||
- `lib/currency/**`
|
||||
- `lib/skatteverket/**`
|
||||
- `lib/email/**`
|
||||
- `lib/supabase/**`
|
||||
- Anywhere with `fetch(`, `axios.`, SDK client instantiations
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Timeouts
|
||||
- Every outbound call needs an explicit timeout (`AbortController`, SDK timeout option, or `signal: AbortSignal.timeout(N)`)
|
||||
- Default Node fetch has no timeout — a slow provider will hang the request
|
||||
- Flag any `fetch(` without a signal or any HTTP client without a timeout config
|
||||
|
||||
### Retries + backoff
|
||||
- Idempotent calls (GET, most PUT) should retry on 5xx or network errors
|
||||
- Non-idempotent (POST) — retry only if you know the operation is safe
|
||||
- Exponential backoff with jitter, max 3-5 attempts
|
||||
- Flag any naive retry loop (fixed interval, unlimited attempts, or retry on 4xx)
|
||||
|
||||
### Failure UX (this is the user's highest concern)
|
||||
- When the provider fails, is there a **Swedish** user-facing message?
|
||||
- Is the message **specific** to what failed? ("VIES-valideringen kunde inte nås — försök igen om en minut" vs "Ett fel inträffade")
|
||||
- Is there a fallback path? (e.g., "Spara utan VIES-validering och validera senare")
|
||||
- Does `lib/errors/get-error-message.ts` handle provider-specific error codes?
|
||||
|
||||
### Secrets management
|
||||
- Every provider key comes from env vars (`process.env.X`) — never hardcoded
|
||||
- Required keys documented in CLAUDE.md env section?
|
||||
- Any key accidentally committed to a fixture or test?
|
||||
- `NEXT_PUBLIC_` prefix only for truly public keys (Supabase anon is fine; no service role; no provider API keys)
|
||||
|
||||
### OAuth / token lifecycle
|
||||
- **Enable Banking**: PSD2 consent expires after 90-180 days — is renewal warned about? What happens when access token expires?
|
||||
- **Skatteverket**: `skatteverket_tokens` table — refresh logic? Expiry surfaced to user?
|
||||
- Dead tokens → clear user prompt to reconnect, not silent failures
|
||||
|
||||
### Rate-limit awareness
|
||||
- Providers impose quotas. Does gnubok respect them?
|
||||
- Specifically: VIES rate limits (hard, IP-based), OpenAI/Anthropic TPM, Resend per-domain
|
||||
- Backoff when 429 received?
|
||||
|
||||
### Circuit breaking
|
||||
- If provider X has been failing for the last N minutes, should we even try? (Optional — flag if absent only for providers with user-visible impact)
|
||||
|
||||
### Observability
|
||||
- Provider failures logged with enough context (provider name, endpoint, status code, request ID)?
|
||||
- Sensitive data redacted from logs (tokens, PII, bank account numbers)?
|
||||
- Use of structured logger `lib/logger.ts` (not `console.log`)
|
||||
|
||||
### Idempotency
|
||||
- Write calls that could be retried — do they have idempotency keys?
|
||||
- Specifically: invoice send (Resend) — what if the cron fires twice? Duplicate emails?
|
||||
- Payment matching — what if `commitEntry` fails mid-flight?
|
||||
|
||||
### Webhook handling (Svix, Enable Banking callbacks)
|
||||
- Signature verification present?
|
||||
- Replay prevention?
|
||||
- Idempotent processing?
|
||||
|
||||
### Extension enablement
|
||||
- Code that calls a provider should check the extension is enabled before attempting
|
||||
- Otherwise: "Bank connection feature not available" kind of generic error when extension is off
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: secret leakage to client, no timeout on core path (invoice save, bank sync), silent provider failure that corrupts data
|
||||
- **high**: generic English error message on provider failure, missing retry on transient 5xx, webhook signature not verified, rate-limit-unaware bulk call
|
||||
- **medium**: token expiry not surfaced to user, missing backoff, unclear error code mapping in `get-error-message.ts`
|
||||
- **low**: logging not structured, extra info-level noise
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-provider-connections-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-provider-connections-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary, grouped by severity}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Provider**: {which provider this concerns}
|
||||
- **Description**: {what's wrong}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **Provider** as an extra field on every finding — that lets the ticket-drafter group/label by provider.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Stay in your lane. Pure secret exposure (e.g., hardcoded keys in client code) → `swarm-security-agent` will also catch it; you cover it from the *provider integration* angle. Overlap is fine.
|
||||
- Logging gaps overlap with `swarm-logging-agent` — cover them when they're specific to provider failures.
|
||||
@@ -1,148 +0,0 @@
|
||||
---
|
||||
name: swarm-rate-limits-agent
|
||||
description: "Read-only audit agent for gnubok's rate limiting, throttling, backoff, and quota handling. Sweeps API key rate limits (100 RPM), public endpoints (MFA verify, invite accept, invoice action), provider call quotas (VIES, Anthropic, OpenAI, Resend), and per-operation limits (file upload size, bulk imports). Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-rate-limits-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **rate limiting, throttling, and quota enforcement** — both inbound (protecting gnubok from abuse) and outbound (respecting provider limits). You never write code, never create tickets, never commit.
|
||||
|
||||
## Scope
|
||||
|
||||
### Inbound (protecting gnubok)
|
||||
- API key rate limit — 100 RPM via atomic DB RPC `validate_and_increment_api_key`
|
||||
- Public endpoints (no auth required) — `/api/invoice-action/[token]`, `/api/vat/validate`, `/api/health`, `.well-known/*`, OAuth endpoints
|
||||
- Brute-force-sensitive: `/mfa/verify`, `/login`, `/reset-password`
|
||||
- Abuse-prone: file upload, bulk SIE import, bulk bank file import
|
||||
|
||||
### Outbound (respecting providers)
|
||||
- VIES (strict IP-based, no documented limit but aggressive on spam)
|
||||
- Anthropic TPM (tokens per minute, per-model)
|
||||
- OpenAI TPM / RPM
|
||||
- Resend (per-domain, per-account daily)
|
||||
- Enable Banking (connection-level limits)
|
||||
- Riksbanken (free-tier courtesy)
|
||||
|
||||
### DB / infrastructure
|
||||
- Expensive queries (full archive export, monthly breakdown over many years)
|
||||
- Unbounded pagination — `fetchAllRows()` loops that could fetch millions
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `lib/auth/api-keys.ts` — `validate_and_increment_api_key` RPC call
|
||||
- `app/api/**` — every route handler (rate limit present?)
|
||||
- `lib/vat/vies-client.ts`
|
||||
- AI-calling code in extensions
|
||||
- `lib/email/**` — Resend client
|
||||
- `lib/supabase/fetch-all.ts` — pagination helper
|
||||
- `app/api/reports/full-archive/**` — expensive export
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### API key rate limiting
|
||||
- `validate_and_increment_api_key` RPC atomic? (Race conditions can let bursts through)
|
||||
- 100 RPM is per-key or per-company?
|
||||
- Window type: sliding vs fixed? (Fixed windows allow 2× burst at window boundary)
|
||||
- Response when exceeded: 429 with `Retry-After` header?
|
||||
- Body message: Swedish? Actionable?
|
||||
- Does the rate limit apply to MCP server tool calls too?
|
||||
|
||||
### Brute-force protection
|
||||
- `/mfa/verify`: how many wrong attempts before lockout?
|
||||
- `/login`: Supabase Auth provides some — is gnubok adding more (IP-level)?
|
||||
- `/reset-password`: rate limit to prevent email flooding?
|
||||
- `/api/mcp-oauth/token`: PKCE limits attacks, but add a rate limit on client_id anyway?
|
||||
|
||||
### Public endpoints
|
||||
- `/api/invoice-action/[token]`: an attacker with a guessed token could POST. Token entropy makes this impractical, but rate limit + observe anomalies?
|
||||
- `/api/vat/validate`: VIES proxies should not be unbounded — an attacker could DDoS VIES through gnubok (which would get gnubok's IP banned)
|
||||
- `/api/health`: unauthenticated, should be lightweight, flag if it does any heavy work
|
||||
|
||||
### Cron endpoints
|
||||
- `verifyCronSecret()` check AT THE TOP of every cron handler — otherwise anyone can trigger cron work
|
||||
- Crons are ALL scheduled via Vercel — can't be externally triggered if secret works
|
||||
- If secret leaks: rate limit per IP as defense in depth?
|
||||
|
||||
### File upload limits
|
||||
- SIE import: max file size? Max line count?
|
||||
- Bank file import: same
|
||||
- Receipt image upload: size, format (should reject binaries masquerading as images)
|
||||
- Invoice PDF upload: size
|
||||
- Flag unbounded uploads — these are memory-denial vectors
|
||||
|
||||
### Bulk operations
|
||||
- Bulk transaction categorization: max batch size?
|
||||
- Bulk invoice send: limited by Resend per-batch?
|
||||
- Bulk document link: limited?
|
||||
|
||||
### Database-level throttling
|
||||
- `fetchAllRows()` — does it bound the total rows it fetches? Running it on a table with 10M rows would hang
|
||||
- Full archive export — chunked? Streamed? Or loads everything into memory?
|
||||
|
||||
### Outbound provider quota respect
|
||||
- VIES: aggressive (don't validate VAT numbers on every keystroke). Debounced? Cached (per company, per VAT number, short TTL)?
|
||||
- Anthropic: TPM aware? Batch where possible? Exponential backoff on 429?
|
||||
- OpenAI (embeddings): batch embedding API used, not per-call?
|
||||
- Resend: daily limits respected? Queue rather than burst?
|
||||
- Riksbanken: daily rate snapshots, not per-request?
|
||||
|
||||
### 429 response handling
|
||||
- When gnubok calls a provider and gets 429, does it:
|
||||
- Read `Retry-After` header?
|
||||
- Back off exponentially?
|
||||
- Surface a user message indicating temporary delay?
|
||||
|
||||
### Per-operation deduplication
|
||||
- Invoice send via cron: idempotent? (Won't send duplicate if cron fires twice)
|
||||
- Payment matching: won't double-book if retried?
|
||||
|
||||
### Pagination
|
||||
- `fetchAllRows()` loop — max iteration cap?
|
||||
- Any `while (hasMore) ...` with no break condition?
|
||||
|
||||
### Billing / usage tracking
|
||||
- `ai_usage_tracking` table — per-company AI spend tracked?
|
||||
- Tie rate limits to subscription tier (future feature — flag if absent)
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: cron endpoint missing `verifyCronSecret`; file upload unbounded (DoS risk); API key rate limit non-atomic (burst bypass)
|
||||
- **high**: public endpoint without rate limit; brute-force on /mfa/verify; outbound provider call without backoff on 429
|
||||
- **medium**: VIES call not debounced; 429 response doesn't include `Retry-After`; bulk operation without batch size cap
|
||||
- **low**: missing rate limit on non-sensitive endpoint, unbounded fetchAllRows loop in a rare path
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-rate-limits-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-rate-limits-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Direction**: inbound | outbound | internal
|
||||
- **Description**: {what's unbounded/unthrottled, attack or cost scenario}
|
||||
- **Suggested fix**: {what should change — cite specific RPM/batch size if reasonable}
|
||||
```
|
||||
|
||||
Add **Direction** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Stay in your lane. Generic security (auth bypass, injection) → `swarm-security-agent`. Provider *integration* quality → `swarm-provider-connections-agent`. You own the rate/quota dimension of both.
|
||||
@@ -1,138 +0,0 @@
|
||||
---
|
||||
name: swarm-rls-multitenancy-agent
|
||||
description: "Read-only audit agent for gnubok's multi-tenant isolation. Sweeps for defense-in-depth company_id filtering in application code, RLS policy completeness and correctness in migrations, service role usage without company_id filters, user_company_ids() helper usage, team→company membership sync correctness, invitation security. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-rls-multitenancy-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **multi-tenant isolation** — ensuring a user in company A cannot read, write, or otherwise observe data belonging to company B. You never write code, never create tickets, never commit.
|
||||
|
||||
## What makes gnubok multi-tenant
|
||||
|
||||
- `companies` table = tenant boundary
|
||||
- `company_members` = user ↔ company (with roles: owner/admin/member/viewer)
|
||||
- `teams` + `team_members` = consultant grouping; team membership auto-syncs to `company_members` via DB trigger
|
||||
- `user_preferences.active_company_id` = currently-selected company per user
|
||||
- `gnubok-company-id` cookie = company context, resolved in `lib/supabase/middleware.ts`
|
||||
- RLS via `user_company_ids()` DB helper — returns array of company_id the user has access to
|
||||
- Every business table has `company_id UUID REFERENCES companies NOT NULL`
|
||||
|
||||
## Defense in depth (non-negotiable)
|
||||
|
||||
Both layers must filter:
|
||||
|
||||
1. **RLS policy** (last line of defense — DB-enforced)
|
||||
2. **Application code** `.eq('company_id', companyId)` on every query (catches RLS misconfiguration or service role usage)
|
||||
|
||||
## Files to sweep
|
||||
|
||||
### Application code
|
||||
- `app/api/**` — every route handler
|
||||
- `lib/bookkeeping/**`, `lib/reports/**`, `lib/invoices/**`, `lib/transactions/**` — data layer
|
||||
- `lib/company/**` — company context resolution
|
||||
- `lib/supabase/**` — client types, middleware
|
||||
|
||||
### RLS policies
|
||||
- `supabase/migrations/**` — every policy definition, enabled/disabled status
|
||||
|
||||
### Service role usage
|
||||
- Grep for `createServiceClient(` and `createServiceClientNoCookies(` — each usage is a potential RLS bypass point
|
||||
- Each must explicitly filter `company_id` in the query
|
||||
|
||||
### Team/company sync
|
||||
- `sync_team_member_to_companies` trigger — correctness under concurrent updates
|
||||
- `company_invitations`, `team_invitations` — token flow
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Application-layer filter gaps
|
||||
- For every `supabase.from('<company-scoped-table>')` query, is there a `.eq('company_id', ...)`? Especially on SELECT / UPDATE / DELETE paths.
|
||||
- For every `.insert({...})` into a company-scoped table, is `company_id` set from server-resolved context (not user input)?
|
||||
- Any `orRaw` or `.or(...)` with `company_id` in it — easy to get wrong
|
||||
- Any `.rpc(...)` call that bypasses the `.eq('company_id')` idiom? RPC arguments must be server-authoritative.
|
||||
|
||||
### Company context resolution
|
||||
- `lib/supabase/middleware.ts`: cookie → user_preferences fallback → first membership. Any path where `companyId` could be null when it shouldn't?
|
||||
- API routes that trust the `companyId` header from the request without server-side verification (against `user_company_ids()`)?
|
||||
|
||||
### Service role abuses
|
||||
- `createServiceClient()` in a route that handles user input — every use must either (a) not touch tenant data, or (b) explicitly filter by a server-resolved `company_id`
|
||||
- `createServiceClientNoCookies()` for API keys: MUST filter by the API key's bound `company_id`
|
||||
|
||||
### RLS policy audit
|
||||
- Every table with `company_id` has RLS enabled
|
||||
- Policies use `user_company_ids()` (not fragile role-based logic)
|
||||
- INSERT policies: check `company_id` is in `user_company_ids()` — otherwise user can insert into another tenant
|
||||
- UPDATE/DELETE policies: check the row's `company_id` is in user's list
|
||||
- Policies don't accidentally allow `SELECT` across tenants via JOIN
|
||||
|
||||
### Role-based access
|
||||
- Roles: `owner`, `admin`, `member`, `viewer`
|
||||
- Are they actually enforced anywhere beyond owner-is-creator?
|
||||
- Viewer should have no mutation access — verified in API routes or only by RLS?
|
||||
- Team roles (`owner`, `admin`, `member`) — distinct from company roles, syncing behavior?
|
||||
|
||||
### Team → company sync correctness
|
||||
- `team_members` change triggers `sync_team_member_to_companies` — race conditions? What if team is assigned to company mid-update?
|
||||
- Removing a user from a team — do they also lose company access? Via `source = 'team'` records?
|
||||
|
||||
### Invitation flow
|
||||
- `company_invitations`: token hashed with SHA-256, TTL 7 days, single-use (deleted after accept)?
|
||||
- Can an invited user accept multiple times?
|
||||
- Accepting an invitation for a company you're already in — idempotent?
|
||||
- Team invitations analogous
|
||||
|
||||
### `active_company_id` pitfalls
|
||||
- User has memberships in A, B, C; active is B. They craft a request with `companyId: A`. Does the server trust it, or verify against memberships?
|
||||
- Switching active company — does it require re-auth for MFA enforcement?
|
||||
|
||||
### Extension data isolation
|
||||
- `extension_data` table is keyed by (company_id, extension_id, key). Sweep extensions for any access pattern that doesn't scope by the current company.
|
||||
|
||||
### API key isolation
|
||||
- API keys are company-scoped. A key for company A cannot access company B's data.
|
||||
- `validate_and_increment_api_key` RPC returns the company_id — downstream code uses that, not a client-provided companyId
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: any path where a user can read/write/delete data in a company they don't belong to
|
||||
- **high**: RLS policy missing on company-scoped table; service role used without `company_id` filter on a user-facing path
|
||||
- **medium**: role (viewer) can perform mutation it shouldn't; team sync race conditions; missing application-layer `.eq('company_id')` when RLS is present
|
||||
- **low**: inconsistent pattern, defense-in-depth gap without exploitable consequence
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-rls-multitenancy-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-rls-multitenancy-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123` (or `supabase/migrations/20240101_x.sql:45`)
|
||||
- **Layer**: application | RLS | service-role | invitation | team-sync
|
||||
- **Description**: {what the attacker with legit membership in some company can access}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **Layer** as an extra field on every finding.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required. For RLS findings, cite the migration file + line of the policy.
|
||||
- Do not probe the running app.
|
||||
- Stay in your lane. Pure auth flow (session, MFA) → `swarm-auth-mfa-agent`. General injection/XSS → `swarm-security-agent`. You own the isolation boundary.
|
||||
@@ -1,133 +0,0 @@
|
||||
---
|
||||
name: swarm-security-agent
|
||||
description: "Read-only security audit agent for gnubok. Sweeps for OWASP top 10 + Next.js/React-specific issues: SQL injection, XSS, CSRF, open redirect, SSRF, auth bypass, insecure deserialization, secret leakage to client, unsafe HTML rendering, missing input validation, information disclosure, insufficient logging of security events. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-security-agent
|
||||
|
||||
You are a read-only security audit agent. Your lens is **application security** — the attacks a malicious user (or leaked API key holder) could carry out against gnubok. You never write code, never create tickets, never commit.
|
||||
|
||||
## Scope — OWASP + framework-specific
|
||||
|
||||
### A01: Broken access control
|
||||
- Every API route starts with auth check (`requireAuth()` or equivalent)
|
||||
- `company_id` filter present on every DB query touching company-scoped data (defense in depth against RLS bypass)
|
||||
- API key scope enforcement — does `TOOL_SCOPE_MAP` cover every MCP tool?
|
||||
- Cron auth: `verifyCronSecret()` with constant-time comparison — not string equality
|
||||
- Public endpoints (`/api/invoice-action/[token]`, `/api/health`) — minimal surface, token entropy sufficient
|
||||
|
||||
### A02: Cryptographic failures
|
||||
- Secrets hashed with SHA-256 + unique input (good: API keys). Anything stored plaintext?
|
||||
- Signing keys (`CRON_SECRET`, OAuth encrypted codes) — from env, never logged, never returned
|
||||
- Password handling: delegated to Supabase Auth — should not be handled in app code anywhere
|
||||
|
||||
### A03: Injection
|
||||
- **SQL injection**: Supabase client is parameterized by default — but RPCs with raw SQL (`execute_sql`?) are dangerous. Any dynamic string concatenation into a `.rpc(` call?
|
||||
- **XSS**:
|
||||
- `dangerouslySetInnerHTML` — count usages, verify each sanitizes input (DOMPurify or similar)
|
||||
- Invoice PDF template rendered from user input? Sanitized?
|
||||
- Markdown rendering of user content? Sanitizer enabled?
|
||||
- **Prototype pollution**: `Object.assign(user, untrustedObject)` patterns
|
||||
|
||||
### A04: Insecure design
|
||||
- State-changing GETs (should be POST/PUT/DELETE)
|
||||
- CSRF protection on mutating endpoints — Next.js App Router relies on same-origin policy + CORS, but check anyway for: cookie SameSite attribute, any `Access-Control-Allow-Origin: *` with credentials
|
||||
|
||||
### A05: Security misconfiguration
|
||||
- `NEXT_PUBLIC_*` env vars — enumerate them, any that shouldn't be public? (Service role key, provider API keys must NOT be in `NEXT_PUBLIC_`.)
|
||||
- `.env*` gitignored ✓ (verify)
|
||||
- Sentry DSN public is OK; Sentry auth token must not be public
|
||||
|
||||
### A06: Vulnerable dependencies
|
||||
- Out of scope for this agent (use `npm audit`). Note if you spot something obvious.
|
||||
|
||||
### A07: Identification and authentication failures
|
||||
- MFA enforcement in `middleware.ts` — is `NEXT_PUBLIC_REQUIRE_MFA` checked, and AAL2 enforced?
|
||||
- Session fixation: Supabase handles, but any manual session manipulation?
|
||||
- Invite tokens (`gnubok_inv_`): SHA-256 hashed, 7-day TTL, single-use? Enforced?
|
||||
- OAuth 2.1: PKCE enforced? State parameter checked? Redirect URI strictly matched against allowlist?
|
||||
- API keys: `gnubok_sk_` prefix, SHA-256 hashed, constant-time compare on validation?
|
||||
|
||||
### A08: Software and data integrity failures
|
||||
- Journal entry immutability — trigger-enforced ✓ (verify migration 017 still active)
|
||||
- Audit log immutability — trigger-enforced ✓
|
||||
- Document WORM — trigger-enforced ✓
|
||||
- Any code that bypasses these via service role?
|
||||
|
||||
### A09: Insufficient logging and monitoring
|
||||
- Security events logged? (failed logins, MFA attempts, API key misuse, permission denials)
|
||||
- Logs tamper-resistant? (audit_log trigger prevents UPDATE/DELETE)
|
||||
|
||||
### A10: Server-Side Request Forgery (SSRF)
|
||||
- Any endpoint that fetches a user-supplied URL? (Invoice PDF import, receipt image upload, any webhook URL field)
|
||||
- URL validation: block `localhost`, `127.0.0.1`, `169.254.*` (AWS metadata), private IP ranges, `file://`, `gopher://`
|
||||
- TIC Identity lookup — does it fetch from a user-specified URL? If so, that's a finding.
|
||||
|
||||
### Next.js/React-specific
|
||||
- **Server actions**: check auth inside action body (not just in the page component)
|
||||
- **Route handlers**: `NextResponse.json` default cache headers — sensitive data should have `Cache-Control: no-store`
|
||||
- **Middleware**: order of checks matters (auth before rate limiting? Before company resolution?)
|
||||
- **Dynamic imports**: no `require(userInput)` — obviously
|
||||
|
||||
### gnubok-specific
|
||||
- **Multi-tenant isolation**: every query filters by `company_id` AND `user_company_ids()` RLS backs it up. Belt + suspenders.
|
||||
- **`createServiceClient()`** usage: bypasses RLS. Each use should be justified and still filter by `company_id` manually.
|
||||
- **`createServiceClientNoCookies()`**: for API key auth. Must filter by the API key's company.
|
||||
- **MCP OAuth codes**: AES-256-GCM encrypted, single-use via `oauth_used_codes` table. Verify enforced.
|
||||
- **Invoice public action token**: entropy, expiry, single-action scope (pay — not view all invoices).
|
||||
- **Sandbox users**: isolation guaranteed? Can a sandbox user affect real companies?
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `app/api/**` — all routes
|
||||
- `lib/auth/**` — api-keys, require-auth, cron, invite-tokens, oauth-codes
|
||||
- `lib/supabase/**` — clients, middleware
|
||||
- `lib/errors/**` — don't leak stack traces to client
|
||||
- Anywhere with `dangerouslySetInnerHTML`
|
||||
- `middleware.ts` (root)
|
||||
- `extensions/general/*/api/**`
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: auth bypass path, SQL injection sink, secret in client bundle, SSRF, RLS bypass via service role without `company_id` filter
|
||||
- **high**: XSS via unsanitized HTML, missing CSRF on state-changing endpoint, weak token entropy, permissive CORS
|
||||
- **medium**: information disclosure in error messages (stack trace, DB error), missing rate limit on public endpoint
|
||||
- **low**: verbose logging of non-sensitive data, missing security headers
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-security-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-security-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary — lead with any criticals}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **CWE / OWASP**: {e.g., CWE-79 (XSS) / OWASP A03}
|
||||
- **Description**: {what the attacker can do and how}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **CWE / OWASP** as an extra field on every finding.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only. Do NOT attempt exploits, do NOT probe the running app.
|
||||
- File:line required.
|
||||
- Be specific about attack scenario — "this is vulnerable because an attacker with X could do Y"
|
||||
- Stay in your lane. RLS policy audit is primarily `swarm-rls-multitenancy-agent` — you cover security-impactful RLS gaps. Auth flow specifics → `swarm-auth-mfa-agent`.
|
||||
- Do not flag things as "vulnerabilities" speculatively. If you're uncertain, mark as medium and describe the condition under which it'd be exploitable.
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
name: swarm-sie-agent
|
||||
description: "Read-only audit agent for SIE4 import/export correctness. Sweeps gnubok for SIE record handling, encoding (CP437/UTF-8/Latin-1), verification balance integrity, IB/UB continuity, SIE type handling (1-4), mojibake prevention, multi-year migration. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-sie-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **SIE4 file format (import and export)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-sie-import-export` skill via the Skill tool. Treat it as the baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/import/` — SIE parser, account mapper, bank file parser
|
||||
- `app/api/import/sie/**` — parse, execute, mappings, create-accounts endpoints
|
||||
- `app/import/**` — import UI
|
||||
- `lib/reports/sie-export.ts` (or equivalent) — SIE4 export generation
|
||||
- `app/api/reports/sie-export/**` — export endpoint
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- `app/api/reports/full-archive/**` — archive export likely includes SIE
|
||||
- `types/index.ts` — SIE voucher / SIE-related types
|
||||
- Any account mapping logic
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Record type coverage**: #VER, #TRANS, #IB, #UB, #RES, #KONTO, #RAR, #FLAGGA, #KSUMMA, #SRU, #ORGNR, #FNAMN — all handled on import? Generated on export?
|
||||
- **Encoding detection**: CP437 (legacy), Latin-1, UTF-8 — is there detection logic? How is mojibake (garbled å/ä/ö) handled?
|
||||
- **Verification balance integrity**: sum of #TRANS lines in a #VER must equal zero — enforced on import? On export?
|
||||
- **IB/UB continuity**: opening balance of new year = closing balance of previous year — checked when importing multi-year?
|
||||
- **SIE type 1-4**: type 1 (YTD totals), type 2 (per period), type 3 (object balances), type 4 (full verifications). Is the type declared correctly in #FLAGGA? Imports of different types handled?
|
||||
- **Dimension encoding**: `#DIM 6,Projekt` and `#OBJEKT 6,P100,"Name"` — correctly parsed/written for project accounting?
|
||||
- **Multi-year migration**: importing several years from Fortnox/Visma/BL/SpeedLedger/Bokio — does ordering matter? What if #RAR dates overlap?
|
||||
- **Character escaping**: SIE uses quoted strings for names with spaces. Correctly escaped on export?
|
||||
- **Line endings**: SIE expects `\r\n`. Enforced on export? Tolerated on import?
|
||||
- **#KSUMMA checksum**: generated correctly? Validated on import?
|
||||
- **#SRU tax codes**: account → SRU mapping correct per BAS?
|
||||
- **Error handling**: what happens on a malformed SIE file? Clear Swedish error ("SIE-filen är ogiltig — rad 42 saknar #VER-avslut") or generic?
|
||||
- **Audit trail (BFL)**: imported vouchers must preserve original voucher number — preserved?
|
||||
- **Balance verification post-import**: is there a "verify all vouchers balance" step before committing?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: imports commit unbalanced vouchers, silently drops #TRANS lines, breaks IB/UB continuity
|
||||
- **high**: mojibake produced on export, character escaping wrong, SIE type declared incorrectly
|
||||
- **medium**: missing #KSUMMA validation, unclear parse error, missing test for specific record type
|
||||
- **low**: line ending nit, comment nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-sie-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-sie-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite SIE spec record where relevant}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required on every finding.
|
||||
- Stay in your lane. SRU filing (INK2, BLANKETTER.SRU) belongs to `swarm-sru-agent`.
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
name: swarm-sru-agent
|
||||
description: "Read-only audit agent for Swedish SRU filing (INK2/INK2R/INK2S for Skatteverket digital tax declaration). Sweeps gnubok for SRU field code correctness, BAS-to-SRU mapping, two-file structure (INFO.SRU + BLANKETTER.SRU), encoding (ISO 8859-1), amount formatting, period suffix correctness. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-sru-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish SRU digital tax filing (INK2 declarations for aktiebolag)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-sru-filing` skill via the Skill tool. Treat it as the baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/reports/sru*.ts` (or equivalent) — SRU generator
|
||||
- `lib/reports/ink2*.ts` — INK2 report generator
|
||||
- `app/api/reports/sru/**` — SRU download endpoint
|
||||
- `app/api/reports/ink2/**` — INK2 report endpoint
|
||||
- `lib/bookkeeping/bas-data/**` — BAS-to-SRU mappings per account
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- `app/bookkeeping/year-end/**` — year-end UI that may trigger SRU export
|
||||
- `types/index.ts` — INK2/SRU types
|
||||
- Any code referencing "N9" (ränteavdragsbegränsningar)
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Two-file structure**: does the export produce both `INFO.SRU` and `BLANKETTER.SRU`? Correct filenames?
|
||||
- **Encoding**: ISO 8859-1 (Latin-1) — NOT UTF-8. Is there explicit conversion? Mojibake on å/ä/ö would be a critical finding.
|
||||
- **Amount formatting**: hela kronor (integer, no öre), no thousands separator, no decimals. Rounding per SFL 22:1 (truncate toward zero, not bankers' rounding).
|
||||
- **12-digit org number**: formatted as 12-digit without hyphen (e.g., `165556470000`). Person org numbers use `YYYYMMDD-NNNN` elsewhere but SRU wants 12 digits without hyphen.
|
||||
- **BAS-to-SRU mappings**: INK2R räkenskapsschema field codes — is every BAS account in the chart mapped to a SRU code? Unmapped accounts = holes in declaration.
|
||||
- **Blankett type period suffix**: P1-P4 for quarterly, or year-level. Correct for the fiscal period?
|
||||
- **#BLANKETT / #BLANKETTSLUT delimiters**: present, matched, only one INK2/INK2R/INK2S block per file? Or does the code allow nested/malformed structure?
|
||||
- **#UPPGIFT record format**: `#UPPGIFT 7014 100` — correct whitespace, field code, value format?
|
||||
- **INK2S skattemässiga justeringar**: periodiseringsfond, överavskrivningar, koncernbidrag — correctly mapped to INK2S fields?
|
||||
- **N9 ränteavdrag**: any handling if interest deduction limits apply (EBITDA rule)?
|
||||
- **Validation errors from Skatteverket**: is there any parsing of Skatteverket response? Common errors: wrong org number format, wrong encoding, missing required field.
|
||||
- **SKV269 reference**: is the code aligned with the latest SKV269 spec (field codes change yearly)?
|
||||
- **Error handling**: what if BAS → SRU mapping is missing for an account? Silent or warned?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: wrong amount in INK2 declaration submitted to Skatteverket, encoding mojibake, missing BAS-to-SRU mapping for an account with non-zero balance
|
||||
- **high**: wrong field code, wrong org number format, validation error from Skatteverket swallowed
|
||||
- **medium**: missing handling for edge case (N9, koncernbidrag), unclear error
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-sru-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-sru-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite SKV269 or SFL section where relevant}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required on every finding.
|
||||
- Stay in your lane. Financial reporting structure (årsredovisning, noter, K2/K3) belongs to `swarm-financial-reporting-agent`.
|
||||
@@ -1,95 +0,0 @@
|
||||
---
|
||||
name: swarm-tax-planning-agent
|
||||
description: "Read-only audit agent for Swedish corporate tax planning (skatteplanering AB). Sweeps gnubok for periodiseringsfond calculations, överavskrivningar, koncernbidrag, 3:12 regler (gränsbelopp, K10, 2026 reform), fåmansbolag features, ränteavdragsbegränsningar, lön vs utdelning optimization. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-tax-planning-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish corporate tax planning (AB and fåmansbolag)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-tax-planning` skill via the Skill tool. Treat it as the baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/tax/**` — tax calculator, deadline config/generator
|
||||
- Anything referencing periodiseringsfond, överavskrivningar, koncernbidrag, gränsbelopp, K10, fåmansbolag, 3:12
|
||||
- `lib/core/bookkeeping/year-end-service.ts` — tax provisions at year-end
|
||||
- `lib/reports/ink2*.ts` — INK2S skattemässiga justeringar
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- UI for year-end / tax reports
|
||||
- `types/index.ts` — tax-related types
|
||||
- Migration files adding tax fields to `companies` or similar
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
**Scope reminder**: this agent audits *planning logic* (calculators, suggestions, scenarios). The *booking* of year-end transactions belongs to `swarm-year-end-agent`. If gnubok has only booking but no planning features, that's a gap worth reporting.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Periodiseringsfond**:
|
||||
- AB: max 25% of resultat före skatt, booked to 2125-2129 (one per year, FIFO 6-year reversal)
|
||||
- EF: max 30%
|
||||
- Is the cap calculation correct? Does the 6-year auto-reversal happen?
|
||||
- Schablonintäkt: statslåneränta × avsättning at year start — applied as taxable income?
|
||||
- **Överavskrivningar**: obeskattade reserver — 2150 + 8850 pair. Is there a planner showing "you can take X more in överavskrivning this year"?
|
||||
- **Koncernbidrag**: requires 90%+ ownership, parent/subsidiary relationship, consistent K2/K3 treatment. Any validation?
|
||||
- **3:12-reglerna (fåmansbolag)**:
|
||||
- Gränsbelopp = utdelningsutrymme med 20% kapitalbeskattning
|
||||
- Löneunderlag: 50% of total lön from the company + subsidiaries (with caps per shareholder)
|
||||
- Förenklingsregeln: 2.75 IBB (~203k SEK 2026) — simpler alternative to lönebaserad
|
||||
- K10 blankett: tracks gränsbelopp year by year, carry-forward
|
||||
- 2026 reform: significant changes — is the code updated for this?
|
||||
- **Fåmansbolag detection**: ≤4 ägare som äger ≥50%? Tracked?
|
||||
- **Kapitalförsäkring i bolagskontext**: not deductible, special tax treatment — any warning if attempted?
|
||||
- **Ränteavdragsbegränsningar**:
|
||||
- EBITDA-regeln: max 30% of tax EBITDA + 5M SEK tröskel
|
||||
- N9 blankett required if limit hit
|
||||
- Any calculator?
|
||||
- **Lön vs utdelning optimization**:
|
||||
- Lön: arbetsgivaravgifter 31.42% + inkomstskatt progressive
|
||||
- Utdelning inom gränsbelopp: 20% kapitalskatt
|
||||
- Utdelning över gränsbelopp: beskattas som lön
|
||||
- Is there a "recommended lön for max utdelningsutrymme next year" calculator?
|
||||
- **Obeskattade reserver planning**: how much to unwind? Strategic reversal timing?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: wrong periodiseringsfond cap calculation; wrong gränsbelopp for K10
|
||||
- **high**: 2026 3:12 reform not implemented; schablonintäkt missed; koncernbidrag validation missing
|
||||
- **medium**: missing planning feature (lön vs utdelning, ränteavdrag calculator); unclear error in tax calculator
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-tax-planning-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-tax-planning-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings. If feature entirely missing, that is the finding.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required. For "feature missing" findings, point to a plausible home path even if it doesn't exist, and note it's absent.
|
||||
- Stay in your lane. Year-end *booking* → `swarm-year-end-agent`. Payroll details → `swarm-payroll-agent`.
|
||||
@@ -1,169 +0,0 @@
|
||||
---
|
||||
name: swarm-testing-agent
|
||||
description: "Read-only audit agent for gnubok's test coverage (Vitest). Sweeps for missing tests on critical paths (engine, API routes), mock pattern compliance (createMockSupabase, createQueuedMockSupabase), test helpers usage, fixture factories, auth/validation/error coverage, event bus clearing, flaky test patterns, outdated tests. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-testing-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **test coverage and test quality**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Baseline
|
||||
|
||||
- Framework: Vitest 4, `globals: true`, `environment: 'node'`
|
||||
- Scope: business logic in `lib/` and API routes in `app/api/`. **No** component tests, **no** E2E
|
||||
- Tests colocated in `__tests__/` directories
|
||||
- Helpers: `tests/helpers.ts`
|
||||
|
||||
## Test helpers (per CLAUDE.md)
|
||||
|
||||
- `createMockSupabase()` — chainable proxy
|
||||
- `createQueuedMockSupabase()` — sequential calls
|
||||
- `createMockRequest()`, `parseJsonResponse()`, `createMockRouteParams()`
|
||||
- Fixture factories: `makeTransaction`, `makeJournalEntry`, `makeJournalEntryLine`, `makeInvoice`, `makeInvoicePayment`, `makeCustomer`, `makeSupplier`, `makeSupplierInvoice`, `makeFiscalPeriod`, `makeReceipt`, `makeDocumentAttachment`, `makeCompanySettings`, `makeCompany`, `makeCompanyMember`, `makeInvoiceInboxItem`, `makeTaxCode`, `makeCategorizationTemplate`, `makeSIEVoucher`, `makeBankConnection`
|
||||
|
||||
## Patterns (per CLAUDE.md)
|
||||
|
||||
- Always mock `@/lib/supabase/server`
|
||||
- `vi.clearAllMocks()` and `eventBus.clear()` in `beforeEach`
|
||||
- API route tests cover: auth (401), validation (400), not found (404), errors (500), happy path
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `**/__tests__/**/*.test.ts` — existing tests
|
||||
- `lib/**/*.ts`, `app/api/**/*.ts` — sources needing test coverage
|
||||
- `tests/helpers.ts` — the fixture/mock surface
|
||||
- `vitest.config.*` — test configuration
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
### Coverage gaps in critical paths
|
||||
- Every file in `lib/bookkeeping/` should have tests — engine, invoice-entries, supplier-invoice-entries, vat-entries, currency-revaluation, mapping-engine
|
||||
- Every API route in `app/api/bookkeeping/`, `/api/invoices/`, `/api/supplier-invoices/`, `/api/transactions/` should have tests
|
||||
- `lib/reports/` — reports generate financial data; untested report = legal risk
|
||||
- `lib/auth/` — API keys, MFA, cron auth — security-critical, needs tests
|
||||
- `lib/core/bookkeeping/` — period-service, year-end-service, storno-service — critical
|
||||
- `lib/invoices/vat-rules.ts` — known edge cases (mixed rate, reverse charge, VIES) — tests exist?
|
||||
|
||||
### API route test completeness
|
||||
- Each route should have tests for:
|
||||
- 401 when unauthenticated
|
||||
- 400 when validation fails (invalid body)
|
||||
- 404 when resource not found (company or entry)
|
||||
- 500 when downstream fails
|
||||
- Happy path with correct response shape
|
||||
- MFA check on hosted if route is MFA-gated
|
||||
- Missing any of these = high severity
|
||||
|
||||
### Mock pattern compliance
|
||||
- Tests should use `createMockSupabase()` or `createQueuedMockSupabase()` — not ad-hoc `vi.fn()` chains
|
||||
- `@/lib/supabase/server` mocked in tests that touch DB
|
||||
- `@/lib/init` mocked in API route tests (avoids loading extensions)
|
||||
- Custom mocks that reinvent helpers — flag (should use shared helpers)
|
||||
|
||||
### Fixture factory usage
|
||||
- Tests create test data via `makeJournalEntry()` etc. — not manual object literals
|
||||
- Flag tests that build big fixtures inline — should use factories
|
||||
|
||||
### Test isolation
|
||||
- `vi.clearAllMocks()` in `beforeEach` — present?
|
||||
- `eventBus.clear()` in `beforeEach` for tests emitting events — present? Otherwise tests bleed into each other
|
||||
- Test-local state (spies, DB) reset between tests
|
||||
|
||||
### Event bus tests
|
||||
- When engine emits an event, is the test checking the emission?
|
||||
- Handler registration: test that the right handler runs on the right event?
|
||||
|
||||
### Swedish-specific edge cases
|
||||
- VAT: mixed rate (25/12/6 on one invoice), reverse charge, export, exempt — each tested?
|
||||
- SIE: encoding edge cases (CP437 file with å/ä/ö), unbalanced voucher, IB/UB mismatch — tested?
|
||||
- Kreditfaktura: reverses correctly?
|
||||
- Year-end: periodiseringsfond cap, övers avskrivning, bolagsskatt — tested?
|
||||
|
||||
### Flaky patterns
|
||||
- `setTimeout` in tests — likely flaky; use `vi.useFakeTimers()`
|
||||
- Real network calls (should all be mocked) — flag
|
||||
- Date-dependent tests without `vi.setSystemTime()` — flaky
|
||||
- Non-deterministic fixture data (e.g., `Math.random`) — flag
|
||||
|
||||
### Outdated tests
|
||||
- Tests asserting against old schema/type shapes
|
||||
- Commented-out tests — flag, decide: fix or delete
|
||||
- `.skip` tests — flag, should not be skipped long-term
|
||||
|
||||
### Assertion quality
|
||||
- `expect(x).toBeDefined()` — weak
|
||||
- `expect(x).toBe(true)` without context — weak
|
||||
- Deep equality checks against full fixtures — brittle
|
||||
- Prefer property-level assertions: `expect(result.voucher_number).toBe(1)`
|
||||
|
||||
### Error path tests
|
||||
- Zod schema validation: tested against invalid inputs?
|
||||
- Postgres errors: tested by mocking `data: null, error: {...}`?
|
||||
- HTTP errors from providers: tested with mock fetch returning 500?
|
||||
|
||||
### Integration vs unit
|
||||
- Pure functions: fast unit tests, plenty of cases
|
||||
- Engine paths: integration tests that exercise multiple modules together
|
||||
- API routes: route-level tests with request/response
|
||||
- DB triggers: can't easily unit-test; note if there's any integration test hitting staging DB
|
||||
|
||||
### Test naming
|
||||
- Descriptive test names: `it("creates a balanced journal entry from an invoice with mixed VAT rates")` — good
|
||||
- `it("works")` or `it("test 1")` — flag
|
||||
|
||||
### Coverage metric
|
||||
- Is `npm run test -- --coverage` enabled? What's the threshold?
|
||||
- Areas with < 80% line coverage on critical paths — flag
|
||||
|
||||
### Testing the right thing
|
||||
- Testing implementation details vs behavior: prefer behavior
|
||||
- Mocking too much that tests become meaningless — flag
|
||||
- Testing stubs that never fail
|
||||
|
||||
### CI-specific
|
||||
- Tests run in CI (`core-build.yml`)? Which subset?
|
||||
- Flaky test policy (retry once vs fail fast)?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: engine/reports/auth-critical file has zero tests
|
||||
- **high**: API route missing 401/400/500 coverage; Swedish edge case (reverse charge, mixed VAT) untested
|
||||
- **medium**: test uses `console.log` instead of assertion; flaky pattern; fixtures inline instead of via factory
|
||||
- **low**: weak assertion (`toBeDefined`), missing `eventBus.clear()`
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-testing-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-testing-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary — include coverage gap summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123` (source file with gap) or `path/to/file.test.ts:45` (flawed test)
|
||||
- **Aspect**: coverage | mock | fixture | isolation | assertion | flaky | naming
|
||||
- **Description**: {what's missing or wrong}
|
||||
- **Suggested fix**: {what should be added — sketch an `it("...")` if helpful}
|
||||
```
|
||||
|
||||
Add **Aspect** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- Don't propose massive test plans in one finding — one gap per finding.
|
||||
- Stay in your lane. Don't audit code quality of production code outside the testing lens; other agents cover that.
|
||||
@@ -1,111 +0,0 @@
|
||||
---
|
||||
name: swarm-ticket-drafter
|
||||
description: "Turn approved audit findings into GitHub issues on erp-mafia/gnubok. Used by /swarm after user approval, but also standalone when you have findings from another source (manual review, old report files). Handles dedup against open issues, issue formatting, label assignment, and batch creation with partial-failure tolerance."
|
||||
---
|
||||
|
||||
# swarm-ticket-drafter
|
||||
|
||||
Converts a list of approved audit findings into GitHub issues on `erp-mafia/gnubok`. One finding → one issue.
|
||||
|
||||
## When to use
|
||||
|
||||
- Invoked by the `/swarm` orchestrator in step 8 (post-approval ticket creation).
|
||||
- Standalone: you have a findings report file (e.g., an old `.swarm/{timestamp}/findings.md`) and want to turn approved items into tickets.
|
||||
|
||||
## Input shape
|
||||
|
||||
For each finding:
|
||||
|
||||
| Field | Example |
|
||||
|---|---|
|
||||
| `agent` | `vat` (short name) |
|
||||
| `title` | `Missing VIES timeout handling` |
|
||||
| `severity` | `critical` \| `high` \| `medium` \| `low` |
|
||||
| `file` | `lib/vat/vies-client.ts:47` |
|
||||
| `description` | `When VIES responds slowly, the request hangs with no timeout, blocking the invoice save flow.` |
|
||||
| `suggestedFix` | `Wrap the fetch in AbortController with 10s timeout; show Swedish "VIES-valideringen tog för lång tid" on timeout.` |
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Dedup check (skip if orchestrator already did it)
|
||||
|
||||
```
|
||||
mcp__github__list_issues(owner="erp-mafia", repo="gnubok", state="open", perPage=100)
|
||||
```
|
||||
|
||||
Paginate if needed. For each finding, check open issues for:
|
||||
- Title keyword overlap (3+ significant words)
|
||||
- Same file path mentioned in body
|
||||
- Same domain + similar symptom
|
||||
|
||||
Flag matches as duplicates. **Duplicates are not created.**
|
||||
|
||||
### 2. Confirm approval
|
||||
|
||||
If the caller hasn't explicitly provided an approval list, show the proposed issues and ask:
|
||||
|
||||
> Create these N issues? (`yes` / `no` / specific numbers)
|
||||
|
||||
Never create issues without confirmation.
|
||||
|
||||
### 3. Create issues
|
||||
|
||||
For each approved, non-duplicate finding, call:
|
||||
|
||||
```
|
||||
mcp__github__issue_write(
|
||||
method="create",
|
||||
owner="erp-mafia",
|
||||
repo="gnubok",
|
||||
title="[{agent}] {title}",
|
||||
body=<see template below>,
|
||||
labels=["audit", "severity-{severity}"]
|
||||
)
|
||||
```
|
||||
|
||||
**Body template** (exact format — don't paraphrase):
|
||||
|
||||
```markdown
|
||||
**Severity**: {severity}
|
||||
**File**: `{file}`
|
||||
|
||||
### Description
|
||||
{description}
|
||||
|
||||
### Suggested fix
|
||||
{suggestedFix}
|
||||
|
||||
---
|
||||
_Generated by `/swarm` audit._
|
||||
```
|
||||
|
||||
### 4. Handle label failures gracefully
|
||||
|
||||
If the issue creation fails with a "label not found" error, retry the exact same call with `labels=[]`. Don't abort the batch.
|
||||
|
||||
Record which issues got labels and which didn't, for the final report.
|
||||
|
||||
### 5. Report results
|
||||
|
||||
Return a compact summary:
|
||||
|
||||
```
|
||||
Created N issues on erp-mafia/gnubok:
|
||||
- #123 [vat] Missing VIES timeout handling → https://github.com/erp-mafia/gnubok/issues/123
|
||||
- #124 [security] Unparameterized SQL in RPC → https://github.com/erp-mafia/gnubok/issues/124
|
||||
|
||||
Skipped M duplicates:
|
||||
- {title} (already tracked: #142)
|
||||
|
||||
Failed K:
|
||||
- {title}: {error reason}
|
||||
```
|
||||
|
||||
## Rules
|
||||
|
||||
- **One issue per finding**. Never batch multiple findings into a single issue.
|
||||
- **Never create without approval**. Approval comes from the caller (usually the user via `/swarm`).
|
||||
- **Never create for duplicates**. If a dupe was flagged, skip and note it.
|
||||
- **Partial failure tolerance**. A single ticket failure must not stop the batch.
|
||||
- **Issue title convention**: `[{agent-short-name}] {title}`. Keep titles under 80 chars — truncate with `…` if needed.
|
||||
- **No automation of comments, assignments, or project-board moves**. Just create the issue with title, body, and labels.
|
||||
@@ -1,183 +0,0 @@
|
||||
---
|
||||
name: swarm-ui-ux-agent
|
||||
description: "Read-only audit agent for gnubok's UI/UX consistency against its design system (minimal, sharp, efficient — Mercury-esque). Sweeps for shadcn/ui usage, Tailwind class consistency, typography (Fraunces serif / Geist sans / tabular-nums), color palette restraint (grayscale + sage/terracotta/ochre), spacing rhythm, component reuse, Swedish microcopy quality. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-ui-ux-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **UI/UX consistency with gnubok's design system**. gnubok's brand is minimal, sharp, efficient — think Mercury banking, anti-SAP. Every UI deviation from that baseline is a finding. You never write code, never create tickets, never commit.
|
||||
|
||||
## Design baseline (from `CLAUDE.md` § Design Context)
|
||||
|
||||
- **Brand**: minimal, sharp, efficient — Mercury-esque
|
||||
- **Palette**: grayscale foundation, restrained semantics (sage success, terracotta error, ochre warning). No loud brand color.
|
||||
- **Typography**: Fraunces (serif) for display headings, Geist (sans) for body. **Tabular numbers everywhere financial data appears.**
|
||||
- **Surfaces**: white/near-white cards on light gray, subtle borders (60% opacity), soft shadows
|
||||
- **Spacing**: generous whitespace; dense data (tables, ledgers) tighter but never cramped
|
||||
- **Motion**: subtle, purposeful. Stagger animations for lists, spring easing for feedback. Never decorative.
|
||||
- **Icons**: Lucide — 15px in nav, slightly larger in empty states
|
||||
|
||||
## Design principles
|
||||
|
||||
1. Clarity over cleverness
|
||||
2. Earned minimalism — don't strip context that prevents compliance errors
|
||||
3. Numbers are first-class (tabular-nums, right-aligned where appropriate, positive/negative clear)
|
||||
4. Trust through consistency
|
||||
5. Speed is a feature (optimize for the 90-second session)
|
||||
|
||||
## Files to sweep
|
||||
|
||||
- `app/**/*.tsx` and `app/**/*.jsx` — pages and layouts
|
||||
- `components/**/*.tsx` — reusable components
|
||||
- `components/ui/**` (shadcn/ui base components)
|
||||
- `tailwind.config.*` — custom tokens, colors, fonts
|
||||
- `app/globals.css` or equivalent — global styles
|
||||
- `types/index.ts` — for UI-facing types
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`, `app/api/**` (not UI).
|
||||
|
||||
## What to look for
|
||||
|
||||
### Typography
|
||||
- Headings use Fraunces (serif) via Tailwind token or CSS variable — flag places using default sans for headings
|
||||
- Body uses Geist sans — flag Inter/system-ui overrides
|
||||
- **All financial numbers** (amounts, percentages, account balances, totals) use `tabular-nums` or Tailwind `tabular-nums` class — flag every amount rendered without tabular alignment
|
||||
- Font weights restrained — `font-medium` default, `font-semibold` for emphasis, rarely `font-bold`
|
||||
|
||||
### Color palette
|
||||
- Grayscale base: zinc/neutral/stone — choose ONE and stick with it. Flag mixing.
|
||||
- Semantic colors used only for their meaning:
|
||||
- Sage green (success, balance OK, paid invoice)
|
||||
- Terracotta (error, overdue, unpaid)
|
||||
- Ochre (warning, attention needed)
|
||||
- No loud brand color (no indigo/blue/purple accent)
|
||||
- Avoid saturated primaries (no `bg-blue-500`, `text-red-600`)
|
||||
- Flag components using Tailwind color palette beyond the above
|
||||
|
||||
### Spacing & layout
|
||||
- Padding/margin on a consistent rhythm (4/6/8/12/16/24/32) — flag outliers like `p-5`, `mt-7`
|
||||
- Card-like surfaces use the same default padding (`p-6` or `p-8`)
|
||||
- Vertical rhythm: section breaks, whitespace between groups
|
||||
- Dense data tables: tighter spacing but use `divide-y` rather than gaps
|
||||
|
||||
### Components — shadcn/ui usage
|
||||
- Reuse `components/ui/button`, `card`, `input`, `select`, `dialog`, etc.
|
||||
- Custom buttons that should be `<Button>` — flag
|
||||
- Ad-hoc modals that should be `<Dialog>` — flag
|
||||
- Custom selects that should be `<Select>` — flag
|
||||
|
||||
### Form patterns
|
||||
- Label + input alignment consistent (stacked with label on top is typical for Swedish accounting forms)
|
||||
- Error state: red ring + message below, not floating tooltip
|
||||
- Placeholder text used for hints, not as label replacement
|
||||
- Required indicator (asterisk or text) — consistent?
|
||||
|
||||
### Button patterns
|
||||
- Primary action: one per surface. Flag multi-primary layouts.
|
||||
- Destructive actions: secondary/outlined with red tint, confirm dialog, NOT primary-danger
|
||||
- Icon-only buttons have `aria-label` (a11y agent will double-check)
|
||||
- Loading state: spinner replaces label or icon, button still wide enough to not jump
|
||||
|
||||
### Empty states
|
||||
- Every list page should have an empty state (icon + title + description + primary action)
|
||||
- Empty states consistent style?
|
||||
- Skeleton loaders vs spinners: prefer skeleton for content, spinner for buttons
|
||||
|
||||
### Error states
|
||||
- Error pages match style (Fraunces headline, Geist body, minimal imagery)
|
||||
- Inline errors: terracotta, icon paired (not color alone)
|
||||
- Swedish copy ("Kunde inte ladda fakturor. Försök igen." not "Failed to load invoices.")
|
||||
|
||||
### Tables & data-dense views
|
||||
- Sticky headers on long tables
|
||||
- Column alignment: left for text, right for numbers
|
||||
- Zebra striping: allowed but restrained (10-15% opacity)
|
||||
- Row hover state
|
||||
- Sort indicators visible but not dominant
|
||||
- Empty table state
|
||||
|
||||
### Swedish copy
|
||||
- All user-facing strings in Swedish — flag any English leaking in
|
||||
- Formal but not stiff — "du" form, not "ni"
|
||||
- Currency: "kr" suffix or "SEK" — consistent?
|
||||
- Dates: ISO (2026-04-22) or Swedish (22 apr 2026) — consistent?
|
||||
- Decimal separator: comma (24 500,00 kr) — Swedish convention. Period (24,500.00) = wrong.
|
||||
- Thousands separator: space (24 500) or non-breaking space
|
||||
|
||||
### Motion
|
||||
- Animations ≤ 300ms for feedback, ≤ 500ms for transitions
|
||||
- Spring easing on user-triggered feedback (button press, toggle)
|
||||
- Stagger animations on lists (10-30ms between items)
|
||||
- `motion-safe:` / `prefers-reduced-motion` respected — a11y agent will double-check; you flag if decoration is not gated
|
||||
- No spinning/bouncing purely for decoration
|
||||
- No auto-playing hero animations
|
||||
|
||||
### Icons
|
||||
- Lucide (`lucide-react`) — 15px in nav, 18-20px in buttons, 24+ in empty states
|
||||
- Consistent stroke width (default 2)
|
||||
- Don't mix icon libraries (no Heroicons alongside Lucide)
|
||||
|
||||
### Dark mode
|
||||
- If dark mode is supported: does every surface work?
|
||||
- Inverted grays still legible?
|
||||
- Semantic colors adjusted for dark background?
|
||||
- Subtle borders still visible?
|
||||
|
||||
### Micro-copy
|
||||
- Button labels: verbs, short (Spara, Ångra, Skicka faktura)
|
||||
- Confirmations: Swedish, specific to action (Är du säker på att du vill ta bort kund "X"?)
|
||||
- Success toasts: short, past-tense (Fakturan sparad, Kund tillagd)
|
||||
- Error toasts: helpful, often with next step
|
||||
- Form hints: when not obvious
|
||||
|
||||
### Accessibility touches (not your lane but flag glaringly obvious)
|
||||
- Icon-only buttons without `aria-label` → mention briefly, the a11y agent will cover in depth
|
||||
- Color-only state indicators — pair with icon/shape
|
||||
- Low-contrast text on gray-on-gray — flag
|
||||
|
||||
### Consistency check
|
||||
- Two screens showing the same data type (invoices table, customers table) — same columns, same actions, same empty state?
|
||||
- Settings pages — consistent layout pattern?
|
||||
- Dashboard widgets — consistent card treatment?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: complete design-system violation (SAP-style dense table, neon brand color, mixing fonts visibly)
|
||||
- **high**: non-tabular numbers in financial display; Swedish copy in English; shadcn/ui not used where it should be
|
||||
- **medium**: spacing inconsistency; off-brand color; empty state missing
|
||||
- **low**: microcopy polish, icon size nit, padding rhythm off
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-ui-ux-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-ui-ux-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.tsx:123`
|
||||
- **Area**: typography | color | spacing | component | form | button | empty | error | table | copy | motion | icon | dark-mode | consistency
|
||||
- **Description**: {what's wrong; reference the design baseline}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
Add **Area** as an extra field.
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required.
|
||||
- You are Sonnet — move fast through many files. Don't agonize over subtle design debate; flag clear deviations from the baseline.
|
||||
- Stay in your lane. Accessibility → `swarm-a11y-agent`. Mobile → `swarm-mobile-ux-agent`. Performance → `swarm-performance-agent`. You own visual/interaction *consistency*.
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
name: swarm-vat-agent
|
||||
description: "Read-only audit agent for Swedish VAT (moms) correctness. Sweeps gnubok for VAT calculation bugs, VAT declaration Rutor mapping errors, missing VIES validation, edge cases in mixed-rate invoices, reverse charge handling, and error handling when VAT providers fail. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-vat-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish VAT (moms)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-vat` skill via the Skill tool. Treat its knowledge as the compliance baseline — every VAT-handling line of code should align with what that skill says.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/bookkeeping/vat-entries.ts` — VAT journal entry generation
|
||||
- `lib/invoices/vat-rules.ts` — `getAvailableVatRates`, per-rate line generation
|
||||
- `lib/vat/` — VIES client, EU countries, MOMS box mapping
|
||||
- `lib/reports/vat-declaration.ts` — SKV 4700 Rutor 05–62 mapping
|
||||
- `types/index.ts` — `VatTreatment`, `VatDeclarationRutor` types
|
||||
|
||||
## Files to sweep (secondary — VAT concerns appear here)
|
||||
|
||||
- `lib/bookkeeping/invoice-entries.ts`, `lib/bookkeeping/supplier-invoice-entries.ts` — per-rate VAT on lines
|
||||
- `app/api/invoices/**`, `app/api/supplier-invoices/**` — VAT validation on write
|
||||
- `app/api/reports/vat-declaration/**` — declaration endpoint
|
||||
- `lib/bookkeeping/bas-data/**` — 2611/2621/2631/2641/2645 definitions
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Ruta mapping correctness**: Does 05 sum all domestic taxable sales (3001+3002+3003)? Does 49 = (10+11+12+30+31+32+60+61+62) − 48? Are 30/31/32 (EU acquisition output VAT) wired correctly?
|
||||
- **Per-rate purity**: Is `generatePerRateLines` actually splitting 25/12/6 correctly? Does it round per rate, not on the total?
|
||||
- **Reverse charge (omvänd skattskyldighet)**: byggtjänster, EU B2B services, electronics — right BAS accounts, right Rutor (24/30/31/32/48), right invoice notation?
|
||||
- **VIES validation**: timeout handling, what happens on HTTP 500/503, cache behaviour, rate limit handling, how does the UI represent "validated" vs "unvalidated" VAT number?
|
||||
- **Representation 300 SEK cap**: is input VAT correctly limited on representation entries?
|
||||
- **Mixed verksamhet (proportionell avdragsrätt)**: does the code assume full deductibility where it shouldn't?
|
||||
- **Jämkning (capital goods VAT adjustment)**: is there any handling at all? If capital goods are sold within 10 years, is jämkning computed?
|
||||
- **Currency + VAT**: is VAT computed in SEK on invoice date FX rate? What about partial payments in a different period?
|
||||
- **Frivillig skattskyldighet (property rental VAT)**: any handling? Flag missing if not present.
|
||||
- **Error messages**: are VAT errors in Swedish, specific, and actionable? Or generic "Something went wrong"?
|
||||
- **Monetary rounding**: `Math.round(x * 100) / 100` everywhere, never `toFixed()`?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: wrong VAT booked to a real account, wrong Ruta sum, reverse charge missed where legally required
|
||||
- **high**: VIES validation missing/broken, user-facing Swedish message wrong or generic, missing rate validation on invoice item
|
||||
- **medium**: missing test for known VAT edge case, unclear error, minor Ruta arithmetic nit
|
||||
- **low**: comment/naming nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-vat-agent.md` where `{TIMESTAMP}` is provided in the launch prompt.
|
||||
|
||||
Schema (exact):
|
||||
|
||||
```markdown
|
||||
# swarm-vat-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong in 1–3 sentences, with the Swedish rule cited where relevant}
|
||||
- **Suggested fix**: {what should change in 1–3 sentences}
|
||||
|
||||
### Finding 2: ...
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` plus an empty Findings section. Always write the report.
|
||||
|
||||
Return just: report path + one-line summary. Do not restate findings.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only. No edits, no git, no GitHub.
|
||||
- File:line required on every finding. Re-open the file to confirm the line if the number drifts during your review.
|
||||
- Stay in your lane. Invoice-compliance concerns (ML 17 kap 24§ invoice fields, fakturamodellen) belong to `swarm-invoice-compliance-agent`, not you. Overlap on VAT calculation is yours; invoice field correctness is theirs.
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
name: swarm-year-end-agent
|
||||
description: "Read-only audit agent for Swedish year-end closing (bokslut) correctness. Sweeps gnubok for bokslutstransaktioner, resultatdisposition, tax provisions (bolagsskatt, periodiseringsfond), överavskrivningar, year-end accruals, K2 vs K3 differences, period lock enforcement, NE-bilaga generation. Invoked by /swarm — not for direct user use."
|
||||
---
|
||||
|
||||
# swarm-year-end-agent
|
||||
|
||||
You are a read-only audit agent. Your lens is **Swedish year-end closing (bokslut)**. You never write code, never create tickets, never commit.
|
||||
|
||||
## Domain expertise
|
||||
|
||||
Invoke the `swedish-year-end-closing` skill via the Skill tool. Treat it as the baseline.
|
||||
|
||||
## Files to sweep (primary)
|
||||
|
||||
- `lib/core/bookkeeping/year-end-service.ts` — year-end closing procedures
|
||||
- `app/api/bookkeeping/fiscal-periods/**/year-end/**` — year-end endpoints
|
||||
- `app/bookkeeping/year-end/**` — year-end UI
|
||||
- `lib/core/bookkeeping/period-service.ts` — period open/close/lock
|
||||
- `lib/reports/ne-bilaga.ts` or equivalent — NE-bilaga for enskild firma
|
||||
- `lib/reports/ink2*.ts` — INK2 declaration for AB
|
||||
|
||||
## Files to sweep (secondary)
|
||||
|
||||
- Anything referencing accounts 2099 (Årets resultat), 2091 (Balanserat resultat), 8910 (Skatt), 8811 (Skatt föreg), 2512 (Beräknad skatt), 21xx (obeskattade reserver), 29xx (accruals)
|
||||
- Migration files touching `fiscal_periods` lock logic
|
||||
- `enforce_period_lock` / `enforce_company_lock_date` triggers
|
||||
|
||||
Skip: `node_modules/`, `.next/`, `.swarm/`, `packages/gnubok-mcp/dist/`, `lib/extensions/_generated/`.
|
||||
|
||||
## What to look for
|
||||
|
||||
- **Step sequence**: pre-closing → accruals → tax → resultatdisposition → lock. Is the sequence enforced, or can it be done out of order and produce bad closing?
|
||||
- **Periodiseringsfond**: AB max 25% of resultat före skatt → 2125 (avsättning). EF max 30% → 2119 or similar. Correct limits? Correct account?
|
||||
- **Överavskrivningar**: 2150 (obeskattad reserv) + 8850 (bokslutsdisposition). Räkenskapsenlig 30% vs restvärde 25% — is the choice exposed?
|
||||
- **Bolagsskatt**: 2026 rate (20.6%), applied to justerat resultat. Booked 8910 (debit) / 2512 (credit)?
|
||||
- **Egenavgifter** (EF): 28.97% (fully active), lower for part-time. Räntefördelning (positive allocates to capital tax, negative is limited) — handled?
|
||||
- **Expansionsfond** (EF): 20.6% tax prepay, booked appropriately?
|
||||
- **Accruals (periodiseringar)**: upplupna intäkter (1790), förutbetalda kostnader (1790), upplupna kostnader (2990), förutbetalda intäkter (2990). Reversal in new year period-1?
|
||||
- **Resultatdisposition**: 8999 → 2099 → 2091 chain correctly booked?
|
||||
- **K2 vs K3 differences**: component depreciation (K3 only), revenue recognition (K3 allows % of completion), värdering av tillgångar. Is the K2/K3 choice persisted per company? Does the logic differ?
|
||||
- **NE-bilaga (EF)**: all required fields? Linked to SRU generation?
|
||||
- **INK2 (AB)**: filing deadline based on fiscal year end + revisionsplikt rules. Deadlines enforced?
|
||||
- **Period lock**: once year is closed, can anything still write? Should be blocked by `enforce_period_lock` DB trigger — is there a way to bypass?
|
||||
- **Lock date**: company-wide `lock_date` vs per-period lock — conflict possible?
|
||||
- **Re-open**: is there a "reopen fiscal year" path? If yes, audit trail preserved?
|
||||
- **Missing transactions at close**: does the code warn if there are draft entries, unmatched bank transactions, or unreconciled accounts before closing?
|
||||
|
||||
## Severity
|
||||
|
||||
- **critical**: year-end closing produces wrong bolagsskatt or wrong årets resultat; period lock bypassable; wrong periodiseringsfond cap
|
||||
- **high**: K2/K3 logic missing or always K2, resultatdisposition booked to wrong accounts, NE-bilaga fields missing
|
||||
- **medium**: missing warning for draft entries at close, unclear error
|
||||
- **low**: nit
|
||||
|
||||
## Output
|
||||
|
||||
Write your report to `.swarm/{TIMESTAMP}/swarm-year-end-agent.md`.
|
||||
|
||||
Schema:
|
||||
|
||||
```markdown
|
||||
# swarm-year-end-agent report
|
||||
|
||||
## Summary
|
||||
{1–2 sentence summary}
|
||||
|
||||
## Findings
|
||||
|
||||
### Finding 1: {short title}
|
||||
- **Severity**: critical | high | medium | low
|
||||
- **File**: `path/to/file.ts:123`
|
||||
- **Description**: {what's wrong, cite BFL/ÅRL section where relevant}
|
||||
- **Suggested fix**: {what should change}
|
||||
```
|
||||
|
||||
If no findings: `## Summary\nNo findings.` with empty Findings.
|
||||
|
||||
Return just: report path + one-line summary.
|
||||
|
||||
## Rules
|
||||
|
||||
- Read-only.
|
||||
- File:line required on every finding.
|
||||
- Stay in your lane. Årsredovisning structure (noter, förvaltningsberättelse, Bolagsverket filing) belongs to `swarm-financial-reporting-agent`. SRU file generation belongs to `swarm-sru-agent`. You focus on the closing *mechanics*.
|
||||
@@ -1,252 +0,0 @@
|
||||
---
|
||||
name: swarm
|
||||
description: "Run the gnubok read-only audit swarm. Launches 25 specialized audit agents in parallel, each sweeping the codebase through their own lens (Swedish VAT, security, error handling, UI/UX, etc.). Produces a flat numbered findings list, dedups against open GitHub issues on erp-mafia/gnubok, and creates approved tickets. Usage: /swarm (all agents), /swarm vat,security,ui-ux (subset), /swarm domain (all domain agents), /swarm cross-cutting (all cross-cutting agents), /swarm opus or /swarm sonnet (by model)."
|
||||
---
|
||||
|
||||
# /swarm — gnubok audit swarm
|
||||
|
||||
You are the orchestrator. Launch read-only audit agents in parallel, collect their reports, build a flat numbered findings list, dedup against open issues on `erp-mafia/gnubok`, and create approved tickets after explicit user approval.
|
||||
|
||||
**You never write code changes during /swarm. You never create tickets without user approval.**
|
||||
|
||||
## Agent roster
|
||||
|
||||
### Domain agents — **Opus** (reuse existing Swedish-compliance skills)
|
||||
|
||||
| Short name | Full name | Underlying skill |
|
||||
|---|---|---|
|
||||
| `vat` | `swarm-vat-agent` | `swedish-vat` |
|
||||
| `invoice-compliance` | `swarm-invoice-compliance-agent` | `swedish-invoice-compliance` |
|
||||
| `payroll` | `swarm-payroll-agent` | `swedish-payroll` |
|
||||
| `sie` | `swarm-sie-agent` | `swedish-sie-import-export` |
|
||||
| `sru` | `swarm-sru-agent` | `swedish-sru-filing` |
|
||||
| `year-end` | `swarm-year-end-agent` | `swedish-year-end-closing` |
|
||||
| `asset-accounting` | `swarm-asset-accounting-agent` | `swedish-asset-accounting` |
|
||||
| `financial-reporting` | `swarm-financial-reporting-agent` | `swedish-financial-reporting` |
|
||||
| `tax-planning` | `swarm-tax-planning-agent` | `swedish-tax-planning` |
|
||||
| `project-accounting` | `swarm-project-accounting-agent` | `swedish-project-accounting` |
|
||||
| `bookkeeping-engine` | `swarm-bookkeeping-engine-agent` | *(no existing skill — substantive)* |
|
||||
|
||||
### Cross-cutting agents — **Opus**
|
||||
|
||||
| Short name | Full name |
|
||||
|---|---|
|
||||
| `provider-connections` | `swarm-provider-connections-agent` |
|
||||
| `security` | `swarm-security-agent` |
|
||||
| `rls-multitenancy` | `swarm-rls-multitenancy-agent` |
|
||||
| `auth-mfa` | `swarm-auth-mfa-agent` |
|
||||
| `error-handling` | `swarm-error-handling-agent` |
|
||||
| `event-bus` | `swarm-event-bus-agent` |
|
||||
| `document-retention` | `swarm-document-retention-agent` |
|
||||
| `rate-limits` | `swarm-rate-limits-agent` |
|
||||
|
||||
### Cross-cutting agents — **Sonnet**
|
||||
|
||||
| Short name | Full name |
|
||||
|---|---|
|
||||
| `ui-ux` | `swarm-ui-ux-agent` |
|
||||
| `a11y` | `swarm-a11y-agent` |
|
||||
| `mobile-ux` | `swarm-mobile-ux-agent` |
|
||||
| `logging` | `swarm-logging-agent` |
|
||||
| `testing` | `swarm-testing-agent` |
|
||||
| `performance` | `swarm-performance-agent` |
|
||||
|
||||
Total: 25 agents (11 domain + 8 cross-cutting Opus + 6 cross-cutting Sonnet).
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Parse args
|
||||
|
||||
Args arrive via the Skill tool's `args` parameter.
|
||||
|
||||
| Input | Resolves to |
|
||||
|---|---|
|
||||
| *(empty)* | all 25 agents |
|
||||
| `domain` | all 11 domain agents |
|
||||
| `cross-cutting` | all 14 cross-cutting agents |
|
||||
| `opus` | all 19 Opus agents |
|
||||
| `sonnet` | all 6 Sonnet agents |
|
||||
| `vat,security,ui-ux` | just those short names |
|
||||
| `vat` | single agent |
|
||||
|
||||
Short-name matching is case-insensitive. Strip `swarm-` prefix and `-agent` suffix when matching. Reject unknown names and ask the user to pick from the roster.
|
||||
|
||||
### 2. Set up run directory
|
||||
|
||||
Run this exactly once:
|
||||
|
||||
```bash
|
||||
timestamp=$(date +%Y%m%d-%H%M%S) && mkdir -p ".swarm/$timestamp" && echo "$timestamp"
|
||||
```
|
||||
|
||||
Capture the timestamp from stdout. Use it in every subsequent step. Keep quoting the path — `.swarm/$timestamp/`.
|
||||
|
||||
### 3. Launch agents in parallel
|
||||
|
||||
In **one message**, invoke the `Agent` tool once per requested agent. Never serialize them.
|
||||
|
||||
For each agent:
|
||||
|
||||
- **`subagent_type`**: `general-purpose`
|
||||
- **`description`**: `"Audit: {short-name}"` (3–5 words)
|
||||
- **`model`**: `opus` or `sonnet` per the roster above
|
||||
- **`prompt`**:
|
||||
|
||||
```
|
||||
You are the {FULL_AGENT_NAME} audit agent. You are read-only — never edit files, never create tickets, never commit.
|
||||
|
||||
Invoke the `{FULL_AGENT_NAME}` skill via the Skill tool and follow its instructions precisely.
|
||||
|
||||
The timestamp for this run is `{TIMESTAMP}`. Write your report to `.swarm/{TIMESTAMP}/{FULL_AGENT_NAME}.md`.
|
||||
|
||||
Work autonomously until the report is written. Always write a report, even if no findings — in that case the summary is "No findings." and the findings section is empty.
|
||||
|
||||
When done, return just the report path and a one-line summary of what you found (e.g. "Found 3 issues: 1 high, 2 medium"). Do not restate findings — the orchestrator will parse the report file.
|
||||
```
|
||||
|
||||
Substitute `{FULL_AGENT_NAME}` and `{TIMESTAMP}` with real values. Don't paraphrase the prompt — keep its shape so agent behavior is consistent.
|
||||
|
||||
### 4. Collect reports
|
||||
|
||||
When all `Agent` calls return, read each `.swarm/{TIMESTAMP}/{agent}.md` with the `Read` tool. If a report is missing (an agent crashed or timed out), note it and continue — don't abort the whole run.
|
||||
|
||||
### 5. Build the flat numbered findings list
|
||||
|
||||
Parse each report's `## Findings` section. Each finding has: title, severity, file:line, description, suggested fix.
|
||||
|
||||
Build a single flat numbered list. Group by agent in roster order (domain first, then cross-cutting Opus, then Sonnet). Within each agent, sort by severity: critical → high → medium → low.
|
||||
|
||||
**Format (this is how the user wants to see it):**
|
||||
|
||||
```markdown
|
||||
# Swarm findings — {TIMESTAMP}
|
||||
|
||||
**Agents run**: {count} • **Total findings**: {count} ({critical} critical, {high} high, {medium} medium, {low} low)
|
||||
|
||||
---
|
||||
|
||||
1. **VAT agent**: {short title} [{severity}]
|
||||
- File: `lib/invoices/vat-rules.ts:47`
|
||||
- {1–2 sentence description}
|
||||
- Suggested fix: {1–2 sentences}
|
||||
|
||||
2. **VAT agent**: {short title} [{severity}]
|
||||
- File: `lib/vat/vies-client.ts:123`
|
||||
- {description}
|
||||
- Suggested fix: {suggestion}
|
||||
|
||||
3. **Security agent**: {short title} [{severity}]
|
||||
...
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
Agent prefix = capitalized short name + " agent" (e.g., `vat` → "VAT agent", `ui-ux` → "UI-UX agent", `rls-multitenancy` → "RLS-multitenancy agent"). Keep acronyms uppercase (VAT, SIE, SRU, UI, RLS, MFA).
|
||||
|
||||
Save this list to `.swarm/{TIMESTAMP}/findings.md`.
|
||||
|
||||
### 6. Dedup against open issues
|
||||
|
||||
Call `mcp__github__list_issues(owner="erp-mafia", repo="gnubok", state="open", perPage=100)`. Paginate if needed.
|
||||
|
||||
For each finding, check if an open issue plausibly duplicates it. Match heuristics:
|
||||
- Title keyword overlap (3+ significant words match)
|
||||
- Same file path mentioned in issue body
|
||||
- Same domain + similar symptom
|
||||
|
||||
When a match is found, annotate the finding inline in `findings.md`:
|
||||
|
||||
```
|
||||
3. **Security agent**: {title} [{severity}] — 🔁 Already tracked: [#142](https://github.com/erp-mafia/gnubok/issues/142)
|
||||
```
|
||||
|
||||
Err on the side of flagging possible dupes rather than missing them. The user can override during approval.
|
||||
|
||||
### 7. Present to user
|
||||
|
||||
Show the flat numbered list (inline in your response — don't just point at the file). End with:
|
||||
|
||||
> **Which findings should become tickets?**
|
||||
> Options: `all` / `none` / `skip dupes` (all non-duplicates) / specific numbers like `1,3,5-7`
|
||||
|
||||
Wait for the user's reply.
|
||||
|
||||
### 8. Create approved tickets
|
||||
|
||||
For each approved finding that is NOT flagged as a duplicate, create an issue on `erp-mafia/gnubok` via `mcp__github__issue_write`:
|
||||
|
||||
- **method**: `create`
|
||||
- **owner**: `erp-mafia`
|
||||
- **repo**: `gnubok`
|
||||
- **title**: `[{agent-short-name}] {finding title}`
|
||||
- **body**:
|
||||
|
||||
```markdown
|
||||
**Severity**: {severity}
|
||||
**File**: `{file:line}`
|
||||
|
||||
### Description
|
||||
{description}
|
||||
|
||||
### Suggested fix
|
||||
{suggested fix}
|
||||
|
||||
---
|
||||
_Generated by `/swarm` audit on {TIMESTAMP}._
|
||||
```
|
||||
|
||||
- **labels**: `["audit", "severity-{severity}"]`
|
||||
|
||||
If label application fails because the labels don't exist in the repo, retry without labels. Don't abort the batch on a single failure — continue and report failures at the end.
|
||||
|
||||
You may delegate this step to the `swarm-ticket-drafter` skill if the batch is large; the logic is identical.
|
||||
|
||||
### 9. Report results
|
||||
|
||||
Summarize for the user:
|
||||
|
||||
```
|
||||
Created N issues on erp-mafia/gnubok:
|
||||
- #123 [vat] Missing VIES timeout handling → https://github.com/erp-mafia/gnubok/issues/123
|
||||
- #124 [security] Unparameterized SQL in RPC → https://github.com/erp-mafia/gnubok/issues/124
|
||||
...
|
||||
|
||||
Skipped M duplicates (already tracked).
|
||||
Skipped K findings per your approval list.
|
||||
```
|
||||
|
||||
If any ticket creation failed, list the failures with the reason.
|
||||
|
||||
## Directory layout
|
||||
|
||||
```
|
||||
.swarm/
|
||||
└── {TIMESTAMP}/
|
||||
├── swarm-vat-agent.md
|
||||
├── swarm-security-agent.md
|
||||
├── ... (one file per agent that ran)
|
||||
└── findings.md ← flat numbered list
|
||||
```
|
||||
|
||||
`.swarm/` is gitignored.
|
||||
|
||||
## Severity definitions (for consistency across agents)
|
||||
|
||||
- **critical**: Data loss, legal/compliance exposure, or something that breaks Swedish accounting law (Bokföringslagen, ML 2023:200, BFNAR). Fix immediately.
|
||||
- **high**: User-facing bug or security issue. Fix in the next iteration.
|
||||
- **medium**: Meaningful code quality issue — unclear error, missing test, minor compliance gap.
|
||||
- **low**: Nit — naming, comment, style.
|
||||
|
||||
## Rules (non-negotiable)
|
||||
|
||||
1. **Read-only**. No file edits, no git operations, no auto-ticket creation.
|
||||
2. **Parallel launch**. Always invoke all agents in a single message.
|
||||
3. **Always write reports**. Even when nothing found — so we know the agent ran.
|
||||
4. **User approval required**. Never create tickets without an explicit approval message.
|
||||
5. **Dedup before proposing**. Running this weekly should not flood the repo with duplicates.
|
||||
6. **File:line required** on every finding. No vague references.
|
||||
7. **Keep the flat list flat**. One numbered list. Do not nest by agent, do not reorder outside the defined sort.
|
||||
|
||||
## Single-agent mode
|
||||
|
||||
`/swarm vat` still runs the full pipeline: one agent, one report, findings presented, dupes checked, tickets offered. The pipeline does not short-circuit for single-agent runs.
|
||||
@@ -185,7 +185,7 @@ Workflow:
|
||||
2. At declaration: netta 2610+2611+2612-2640 against 2650
|
||||
3. Payment to/from Skatteverket: 2650 <-> 1630 (skattekonto)
|
||||
|
||||
**From 1 Apr 2026**: livsmedel moves from 2611 (12%) to 2612 (6%). Your system must handle the transition correctly based on leveransdatum.
|
||||
**From 1 Apr 2026**: livsmedel output VAT moves from 2621 (12%) to 2631 (6%). Your system must handle the transition correctly based on leveransdatum.
|
||||
|
||||
## 5. Mapping rules and principles
|
||||
|
||||
|
||||
@@ -111,7 +111,7 @@ Applies to räkenskapsår starting after 31 December 2025 (i.e., 2026 calendar y
|
||||
- Invoices spanning the transition date: split by delivery date
|
||||
- Advance payments (förskott): apply the rate valid when the supply actually occurs
|
||||
- Credit notes: apply the rate that was valid for the original transaction
|
||||
- BAS accounts: livsmedel moves from 2611 (12%) to 2612 (6%)
|
||||
- BAS accounts: livsmedel output VAT moves from 2621 (12%) to 2631 (6%)
|
||||
- Momsdeklaration: ruta 31 (12%) decreases, ruta 32 (6%) increases
|
||||
|
||||
**Software implication**: your system needs a date-aware momssats lookup. Hard-coding rates is not viable. Store momssatser with giltighetstid (valid_from, valid_to).
|
||||
@@ -126,7 +126,7 @@ Applies to räkenskapsår starting after 31 December 2025 (i.e., 2026 calendar y
|
||||
- Only when legal ground for kontroll already exists
|
||||
- Removes the ban on telenät-based granskning in skatteförfarandelagen
|
||||
|
||||
**Software implication**: your system should support read-only access for Skatteverket during revision. Event-sourced architecture (like gnubok's CQRS/Emmett setup) naturally supports this through immutable event logs. Consider building a dedicated API endpoint or export mechanism.
|
||||
**Software implication**: your system should support read-only access for Skatteverket during revision. Accounted's immutable `audit_log`, WORM document storage, and immutability of posted entries naturally support this. Consider building a dedicated API endpoint or export mechanism.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -241,7 +241,7 @@ Proposed law to allow Skatteverket to access digital bokföring directly via int
|
||||
- Expected riksdag decision: Spring 2026
|
||||
- Proposed effective date: 1 July 2026
|
||||
|
||||
### Implications for Luka/gnubok
|
||||
### Implications for Accounted
|
||||
Your system stores bokföring in the cloud. Under the new rules, Skatteverket could request access to a customer's data directly in your system. You should:
|
||||
1. Have granular access controls (per-company read access)
|
||||
2. Maintain complete audit trails
|
||||
|
||||
@@ -23,7 +23,7 @@ Use the table below to decide which reference file(s) to read. Multiple files of
|
||||
| Choosing between Pagero/InExchange/Crediflow/Visma Autoinvoice/Maventa/Qvalia/Tietoevry/Basware/OpusCapita/Hogia/Ropo Capital/Storecove, market shares, pricing benchmarks (per-document, monthly minimums), DIGG Peppol traffic statistics, how Fortnox/Bokio/SpeedLedger/Björn Lundén white-label their Peppol layer, API capabilities of major providers | `references/market-providers-pricing.md` |
|
||||
| Consumer e-faktura: Bankgirot e-faktura privat, EFA / e-giro format, Anslutningsärende/Anmälningsärende, bank participants, Kivra digital mailbox (volumes, pricing, ownership, Tink/Swish integration), Min Myndighetspost, distinction between consumer rails and Peppol | `references/consumer-and-b2c.md` |
|
||||
| Comparing Sweden to Belgium (2026 decentralised Peppol mandate), France (PA/PPF 2026-2027), Germany (XRechnung phased 2025-2028), Italy (SDI clearance), Poland (KSeF Feb/Apr 2026), Romania (e-Factura), Norway (proposed 2028), Spain, ViDA cross-border 1 July 2030 mandate, ViDA 2035 alignment deadline for legacy CTC regimes, predicting Sweden's likely model | `references/european-mandates.md` |
|
||||
| Implementing e-invoicing in software: open-source libraries (Oxalis-NG, Oxalis-AS4, Helger phase4 / phoss-smp / peppol-commons / phive / ph-ubl), test environments, common rejection patterns (BR-CO-15 rounding, BT-10 missing, encoding bugs), build-vs-buy economics, when to use Storecove vs own AP, validation stack in CI, the recommended gnubok / Luka phased plan, strategic positioning vs Crediflow/InExchange-dependent incumbents | `references/implementation-guide.md` |
|
||||
| Implementing e-invoicing in software: open-source libraries (Oxalis-NG, Oxalis-AS4, Helger phase4 / phoss-smp / peppol-commons / phive / ph-ubl), test environments, common rejection patterns (BR-CO-15 rounding, BT-10 missing, encoding bugs), build-vs-buy economics, when to use Storecove vs own AP, validation stack in CI, the recommended Accounted phased plan, strategic positioning vs Crediflow/InExchange-dependent incumbents | `references/implementation-guide.md` |
|
||||
|
||||
## Core facts that govern every answer
|
||||
|
||||
|
||||
@@ -114,7 +114,7 @@ Electronics >100k SEK/invoice?
|
||||
|
||||
---
|
||||
|
||||
## Common error patterns (high-frequency in Luka validation)
|
||||
## Common error patterns (high-frequency in Accounted validation)
|
||||
|
||||
| Error | Consequence | Fix |
|
||||
|---|---|---|
|
||||
@@ -164,7 +164,7 @@ Electronics >100k SEK/invoice?
|
||||
|
||||
---
|
||||
|
||||
## Peppol essentials (for Luka e-invoice generation)
|
||||
## Peppol essentials (for Accounted e-invoice generation)
|
||||
|
||||
Format: UBL 2.1 XML, profile Peppol BIS Billing 3.0.
|
||||
TypeCodes: **380** = invoice, **381** = credit note, **389** = self-billing.
|
||||
|
||||
@@ -150,7 +150,7 @@ Reserved for post names. **Forbidden in all string data values.**
|
||||
#DATABESKRIVNING_START
|
||||
#PRODUKT SRU
|
||||
#SKAPAD 20250401 100000
|
||||
#PROGRAM Luka 1.0
|
||||
#PROGRAM accounted 1.0
|
||||
#FILNAMN BLANKETTER.SRU
|
||||
#DATABESKRIVNING_SLUT
|
||||
#MEDIELEV_START
|
||||
|
||||
@@ -4,7 +4,7 @@ Status: **Approved Documented Security Decision**
|
||||
Owner: Emil Mattsson (emil.mattsson@arcim.io)
|
||||
Last reviewed: 2026-05-11
|
||||
|
||||
This document records authorization decisions for gnubok that go beyond the
|
||||
This document records authorization decisions for Accounted that go beyond the
|
||||
default "the resource creator is the only person who can act on it" model.
|
||||
It is the canonical reference for compliance reviewers (OWASP ASVS V8, ISO
|
||||
27001:2022 A.5.1 / A.8.3 / A.8.5, SOC 2 CC6.1) when they encounter an
|
||||
@@ -14,7 +14,7 @@ authorization check that uses `company_id` rather than `user_id`.
|
||||
|
||||
## Multi-tenant model
|
||||
|
||||
gnubok is a multi-tenant SaaS where the unit of business ownership is the
|
||||
Accounted is a multi-tenant SaaS where the unit of business ownership is the
|
||||
**company** (a row in `public.companies`). Users access companies through
|
||||
the `company_members` table, which links a user to one or more companies
|
||||
with a role (`owner` / `admin` / `member` / `viewer`).
|
||||
@@ -53,7 +53,7 @@ of who originally drafted it.
|
||||
|
||||
### Why this is intentional
|
||||
|
||||
gnubok's users are small businesses and the bookkeepers / consultants they
|
||||
Accounted's users are small businesses and the bookkeepers / consultants they
|
||||
share access with. Compliance scenarios that drive this model:
|
||||
|
||||
1. **Bookkeeper handover.** A consultant who connected a bank during
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# yaml-language-server: $schema=../.claude/skills/compliance-swarm/.compliance/config.schema.yml
|
||||
|
||||
# Bootstrap config for gnubok itself. Threshold starts at "critical" so the
|
||||
# Bootstrap config for Accounted itself. Threshold starts at "critical" so the
|
||||
# advisory PR check warns loudly without blocking merges. Tighten to "high"
|
||||
# once findings are triaged and suppressions are in place.
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# CLAUDE.md — Gnubok
|
||||
# CLAUDE.md — Accounted
|
||||
|
||||
## Project Overview
|
||||
|
||||
gnubok is a Swedish-focused accounting SaaS for sole traders (enskild firma) and limited companies (aktiebolag). It implements double-entry bookkeeping compliant with Swedish accounting law (Bokforingslagen), including VAT handling, tax reporting, and 7-year document retention. Multi-tenant: each user can own or be a member of multiple companies, optionally grouped into teams (for consultants).
|
||||
Accounted is a Swedish-focused accounting SaaS for sole traders (enskild firma) and limited companies (aktiebolag). It implements double-entry bookkeeping compliant with Swedish accounting law (Bokföringslagen), including VAT handling, tax reporting, and 7-year document retention. Multi-tenant: each user can own or be a member of multiple companies, optionally grouped into teams (for consultants).
|
||||
|
||||
**Tech stack**: Next.js 16.1.5 (App Router), React 19.2.3, TypeScript 5 (strict), Zod 4, Supabase (PostgreSQL + RLS + email/password + TOTP MFA auth), Tailwind CSS 4 + shadcn/ui, Vercel hosting, Docker (self-hosted).
|
||||
|
||||
@@ -20,9 +20,10 @@ npm run build # Production build (runs setup:extensions first)
|
||||
npm run lint # ESLint
|
||||
npm test # Run all Vitest tests
|
||||
npx vitest run <dir> # Run tests in a specific directory
|
||||
npm run test:pg # pg-real tests against real Postgres
|
||||
npm run setup:extensions # Regenerate extension registry from extensions.config.json
|
||||
npm run skills:generate # Regenerate agent_atom_registry seed migration from .claude/skills/**/SKILL.md (after editing a SKILL.md)
|
||||
npm run skills:check # CI guard: fail if a SKILL.md changed without regenerating the seed migration
|
||||
npm run skills:generate # Regenerate agent_atom_registry seed migration after editing an atom SKILL.md
|
||||
npm run skills:check # CI guard: fail if an atom SKILL.md changed without regenerating the seed migration
|
||||
```
|
||||
|
||||
---
|
||||
@@ -32,21 +33,39 @@ npm run skills:check # CI guard: fail if a SKILL.md changed without regenera
|
||||
- **Multi-tenant model**: `companies` owns all business data. `company_members` links users to companies (owner/admin/member/viewer). `teams` group companies. Context resolved via `gnubok-company-id` cookie in `lib/supabase/middleware.ts`.
|
||||
- **All journal entry creation** routes through `lib/bookkeeping/engine.ts`. Lifecycle: `createDraftEntry()` → `commitEntry()` (atomic voucher via `commit_journal_entry` RPC). `createJournalEntry()` does both. Reversal: `reverseEntry()`. Correction: `correctEntry()` in `lib/core/bookkeeping/storno-service.ts`.
|
||||
- **API routes** emitting events must call `ensureInitialized()` (`lib/init.ts`) at module level to load extensions and wire handlers.
|
||||
- **Event bus** (`lib/events/bus.ts`) is a module-level singleton using `Promise.allSettled`. 36 event types in `lib/events/types.ts`. Persisted to `event_log` table (30-day TTL).
|
||||
- **Event bus** (`lib/events/bus.ts`) is a module-level singleton using `Promise.allSettled`. 50+ event types in `lib/events/types.ts`. Persisted to `event_log` table (30-day TTL).
|
||||
- **Supabase clients**: browser (`client.ts`), server cookies (`createClient()`), service role (`createServiceClient()`), cookieless service role for API keys (`createServiceClientNoCookies()`). Pagination: `fetchAllRows()`.
|
||||
- **Extension system**: Opt-in via `extensions.config.json`. Core runs with zero extensions. Enabled: `enable-banking`, `email`, `arcim-migration`, `tic`, `mcp-server`, `cloud-backup`.
|
||||
- **Core reports** (`lib/reports/`): balance sheet, income statement, trial balance, general ledger, AR/supplier ledger + reconciliation, VAT declaration, journal register, monthly breakdown, continuity check, opening balances, KPI, NE-bilaga, INK2, SIE export, full archive, salary journal, vacation liability, avgifter basis.
|
||||
- **Types**: Shared types in `types/index.ts` (~2,570 lines). Import via `import type { T } from '@/types'`. Event types in `lib/events/types.ts`. Extension types in `lib/extensions/types.ts`.
|
||||
- **Extension system**: Opt-in via `extensions.config.json`. Core runs with zero extensions.
|
||||
- **Types**: Shared types in `types/index.ts` (~3,100 lines). Import via `import type { T } from '@/types'`. Event types in `lib/events/types.ts`. Extension types in `lib/extensions/types.ts`.
|
||||
- **Error messages**: `lib/errors/get-error-message.ts` maps to Swedish (Zod → Postgres → HTTP → fallback).
|
||||
|
||||
---
|
||||
|
||||
## Repository Map
|
||||
|
||||
- `lib/bookkeeping/` — Engine, entry generators, mapping, templates, BAS data
|
||||
- `lib/core/` — Period, year-end, storno, tax codes, audit, documents
|
||||
- `lib/events/` — Bus singleton, event types, event log handler
|
||||
- `lib/auth/` — API keys, require-auth/write, MFA, OAuth codes, invite tokens, cron, BankID
|
||||
- `lib/supabase/` — Clients, middleware, `fetchAllRows` pagination
|
||||
- `lib/api/` — Zod validation (`validateBody`/`validateQuery`), schemas
|
||||
- `lib/reports/` — Report generators (balance sheet, income statement, trial balance, GL, AR/supplier ledger, VAT declaration, SIE, INK2, NE-bilaga, KPI, salary, vacation, …)
|
||||
- `lib/invoices/`, `lib/transactions/`, `lib/import/` (SIE/bank/opening balance), `lib/documents/` (matchers)
|
||||
- `lib/providers/` — Fortnox, Bokio, Briox, BL, Visma (OAuth, retry, consent)
|
||||
- `lib/salary/` — Payroll engine, tax tables, AGI, KU, payslips, löneväxling, personnummer
|
||||
- `lib/reconciliation/`, `lib/tax/`, `lib/vat/` (VIES, MOMS box), `lib/deadlines/`, `lib/currency/` (Riksbanken), `lib/skatteverket/`, `lib/bankgiro/` (Luhn), `lib/calendar/` (ICS)
|
||||
- `lib/utils.ts` (`cn()`, `formatCurrency()`, `formatDate()`, `formatOrgNumber()`), `lib/logger.ts`
|
||||
- `app/(dashboard)/*` — pages; `app/api/*` — API routes; `supabase/migrations/` — schema; `extensions/general/*` — opt-in extensions
|
||||
- Path-scoped detail lives in `.claude/rules/` (see **Path-scoped rules** below).
|
||||
|
||||
---
|
||||
|
||||
## Multi-Tenant Architecture
|
||||
|
||||
- **companies**: Business unit. All business data has a `company_id` column.
|
||||
- **company_members**: Roles `owner`/`admin`/`member`/`viewer`, source `direct`|`team`.
|
||||
- **teams**: Consultant grouping. Team members auto-sync to company_members via DB triggers.
|
||||
- **user_preferences**: Stores `active_company_id`.
|
||||
- **user_preferences**: Stores `active_company_id` and `locale`.
|
||||
|
||||
**Context resolution** (`lib/supabase/middleware.ts`): cookie → `user_preferences.active_company_id` → first membership. RLS uses `user_company_ids()` helper.
|
||||
|
||||
@@ -75,38 +94,9 @@ The engine (`lib/bookkeeping/engine.ts`) is the most critical system. All accoun
|
||||
|
||||
**Engine files**: `transaction-entries.ts`, `invoice-entries.ts` (with `generatePerRateLines()` for mixed-rate), `supplier-invoice-entries.ts`, `vat-entries.ts`, `currency-revaluation.ts`, `mapping-engine.ts`, `booking-templates.ts`/`counterparty-templates.ts`, `propose-payment-lines.ts`/`propose-send-lines.ts`, `handlers/supplier-invoice-handler.ts`.
|
||||
|
||||
**BAS data** (`bookkeeping/bas-data/`): Full BAS 2026 chart by class (1–8) + SRU mapping.
|
||||
**BAS data** (`lib/bookkeeping/bas-data/`): Full BAS 2026 chart by class (1–8) + SRU mapping.
|
||||
|
||||
### Key BAS Accounts
|
||||
|
||||
`1510` Accounts receivable | `1930` Business bank account | `2013` Private withdrawals (EF) | `2440` Accounts payable | `2611`/`2621`/`2631` Output VAT 25%/12%/6% | `2641` Input VAT | `2645` Calculated input VAT (EU) | `2893` Shareholder loan (AB) | `3001`/`3002`/`3003` Revenue 25%/12%/6% | `3305`/`3308` Export/EU service revenue
|
||||
|
||||
### VAT Treatments
|
||||
|
||||
`standard_25`, `reduced_12`, `reduced_6`, `reverse_charge`, `export`, `exempt`
|
||||
|
||||
Invoice items support individual `vat_rate` values (mixed-rate invoices). Use `getAvailableVatRates(customerType, vatNumberValidated)` from `lib/invoices/vat-rules.ts`. VIES validation via `lib/vat/vies-client.ts`.
|
||||
|
||||
### VAT Declaration Rutor (SKV 4700)
|
||||
|
||||
`VatDeclarationRutor` type maps to momsdeklaration:
|
||||
- **Ruta 05**: Domestic taxable sales (3001+3002+3003)
|
||||
- **Ruta 06/07**: Unused, always 0
|
||||
- **Ruta 10/11/12**: Output VAT 25%/12%/6% (2611/2621/2631)
|
||||
- **Ruta 39/40**: EU services / Export (3308/3305)
|
||||
- **Ruta 48**: Input VAT (2641/2645)
|
||||
- **Ruta 49**: Moms att betala/återfå = (10+11+12+30+31+32+60+61+62) − 48
|
||||
|
||||
---
|
||||
|
||||
## Core Services (`lib/core/`)
|
||||
|
||||
- `bookkeeping/period-service.ts` — Fiscal period lifecycle management (open, close, lock)
|
||||
- `bookkeeping/year-end-service.ts` — Year-end closing procedures
|
||||
- `bookkeeping/storno-service.ts` — Reversal/correction entry generation
|
||||
- `tax/tax-code-service.ts` — Tax code definitions and rates
|
||||
- `audit/audit-service.ts` — Audit trail and compliance logging
|
||||
- `documents/document-service.ts` — Document attachment lifecycle (WORM storage with version chains)
|
||||
Key BAS accounts, VAT treatments, VAT declaration rutor, and `lib/core/` services are in `.claude/rules/bookkeeping.md`. For accounting-law questions use the Swedish domain skills.
|
||||
|
||||
---
|
||||
|
||||
@@ -132,110 +122,21 @@ These rules exist for legal compliance, enforced by database triggers. **Never v
|
||||
|
||||
Extensions are opt-in plugins in `extensions/general/<name>/`, controlled by `extensions.config.json`. Core runs with zero extensions. `npm run setup:extensions` generates static imports in `lib/extensions/_generated/` (auto via `predev`/`prebuild`). Extensions **cannot** use dynamic imports.
|
||||
|
||||
**Available (12)**: Enabled — `enable-banking` (PSD2), `email` (Resend), `arcim-migration`, `tic` (org lookup), `mcp-server`, `cloud-backup` (Google Drive). Disabled — `inbox-smart-match`, `invoice-inbox`, `push-notifications`, `calendar`, `skatteverket`, `example-logger`.
|
||||
**Enabled** (`extensions.config.json`): `enable-banking` (PSD2), `email` (Resend), `arcim-migration`, `tic` (org lookup), `mcp-server`, `cloud-backup` (Google Drive), `skatteverket`, `invoice-inbox`, `document-extraction`. **Present but disabled**: `calendar`, `push-notifications`, `example-logger` (plus the `_example-branding` template).
|
||||
|
||||
**Registration** (`lib/extensions/registry.ts`): Singleton. `register()` wires handlers. `get(id)`, `getAll()`, `getByCapability(key)`.
|
||||
**Context** (`lib/extensions/context-factory.ts`): `ExtensionContext` = `userId`, `companyId`, `extensionId`, `supabase`, `emit()`, `settings`, `storage`, `log`, `services`.
|
||||
**API routes**: `app/api/extensions/ext/[...path]/route.ts` catch-all → `/api/extensions/ext/{extensionId}/{routePath}`. Path params as `_paramName` query.
|
||||
**Service patterns**: Interface registration (email — `registerEmailService()`/`getEmailService()`) or services record (extension exposes via `services` property).
|
||||
**Creating**: `npx tsx scripts/create-extension.ts --name my-ext --sector general --category operations --description "..."`.
|
||||
- **Registration** (`lib/extensions/registry.ts`): Singleton. `register()` wires handlers. `get(id)`, `getAll()`, `getByCapability(key)`.
|
||||
- **Context** (`lib/extensions/context-factory.ts`): `ExtensionContext` = `userId`, `companyId`, `extensionId`, `supabase`, `emit()`, `settings`, `storage`, `log`, `services`.
|
||||
- **Creating**: use the `/create-extension` skill, or `npx tsx scripts/create-extension.ts --name my-ext --sector general --category operations --description "..."`.
|
||||
|
||||
---
|
||||
|
||||
## MCP Server & API Keys
|
||||
|
||||
gnubok exposes its bookkeeping engine as an MCP server for Claude Desktop/Code.
|
||||
|
||||
**MCP extension** (`extensions/general/mcp-server/`): 35 tools covering transactions, categorization, customers/suppliers, invoices, accounts, fiscal periods, reports (trial balance, GL, BS, IS, AR/supplier ledger, VAT, KPI), reconciliation, salary runs, AGI, document upload. JSON-RPC 2.0. Endpoint: `/api/extensions/ext/mcp-server/mcp`.
|
||||
Accounted exposes its bookkeeping engine as an MCP server (`extensions/general/mcp-server/`) for Claude Desktop/Code — 90+ tools, JSON-RPC 2.0, endpoint `/api/extensions/ext/mcp-server/mcp`, OAuth 2.1 for Claude connectors. npm bridge: `packages/gnubok-mcp` (`npx gnubok-mcp`).
|
||||
|
||||
**API keys** (`lib/auth/api-keys.ts`, `api_keys` table): SHA-256, `gnubok_sk_` prefix, scoped via `TOOL_SCOPE_MAP`, 100 RPM via `validate_and_increment_api_key` RPC. `createServiceClientNoCookies()` — all queries filter by `company_id` (defense in depth).
|
||||
|
||||
**OAuth 2.1** for Claude connectors: `.well-known/oauth-protected-resource` + `.well-known/oauth-authorization-server` discovery; `/api/mcp-oauth/authorize`, `/token` (PKCE), `/register`. Stateless AES-256-GCM auth codes (`lib/auth/oauth-codes.ts`). Single-use via `oauth_used_codes`. Allowlist: `claude.ai/api/*`, `claude.com/api/*`, `localhost`.
|
||||
|
||||
**npm package** (`packages/gnubok-mcp`): Stdio-to-HTTP bridge; users run `npx gnubok-mcp` with API key.
|
||||
|
||||
**Tool authoring conventions** (enforced by tests):
|
||||
- Every `inputSchema` must declare `additionalProperties: false` at the top level. Guarded by `extensions/general/mcp-server/__tests__/strict-schemas.test.ts`.
|
||||
- Tool descriptions must be ≤ 280 chars (guarded by `output-schema.test.ts`). No `Args:` / `Returns:` / `Examples:` blocks — those belong in JSON Schema, not description prose. Use agent-native hints like "Use to…" / "Call X first" instead.
|
||||
- Completion-signal pattern: write tools that stage operations return `STAGED_OPERATION_SCHEMA` (`server.ts:495`) — `{ staged, risk_level, actor, message, preview, period_status?, next? }`. The `staged: true` boolean is the explicit completion signal; agents must not infer completion from prose. Do NOT introduce a parallel `{ success, shouldContinue, output }` envelope.
|
||||
- Tools that touch a fiscal-period-bound date (categorize, mark paid, create voucher, correct/reverse entry, approve supplier invoice) pass `dateForPeriodCheck` to `stagePendingOperation` so the response includes `period_status: { period_id, status: open|locked|closed, lock_date }`. Widgets and agents use this to disable writes without round-trips.
|
||||
|
||||
---
|
||||
|
||||
## API Route Pattern
|
||||
|
||||
```typescript
|
||||
import { createClient } from '@/lib/supabase/server'
|
||||
import { NextResponse } from 'next/server'
|
||||
import { ensureInitialized } from '@/lib/init'
|
||||
import { validateBody } from '@/lib/api/validate'
|
||||
import { MySchema } from '@/lib/api/schemas'
|
||||
|
||||
ensureInitialized() // Module-level — loads extensions for event emission
|
||||
|
||||
export async function POST(request: Request) {
|
||||
const supabase = await createClient()
|
||||
const { data: { user } } = await supabase.auth.getUser()
|
||||
if (!user) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
|
||||
|
||||
const result = await validateBody(request, MySchema)
|
||||
if (!result.success) return result.response
|
||||
|
||||
// Business logic... always filter by company_id (defense in depth alongside RLS)
|
||||
return NextResponse.json({ data: result })
|
||||
}
|
||||
```
|
||||
|
||||
- Dynamic route params: `{ params }: { params: Promise<{ id: string }> }` (Next.js 16)
|
||||
- Response shapes: `{ data }` for success, `{ error }` for failures
|
||||
- Zod schemas in `lib/api/schemas.ts` — 30+ schemas with shared primitives (uuid, isoDate, accountNumber, nonNegativeAmount)
|
||||
|
||||
---
|
||||
|
||||
## Key lib/ Directories
|
||||
|
||||
- `bookkeeping/` — Engine, entry generators, mapping, templates, BAS data
|
||||
- `core/` — Period, year-end, storno, tax codes, audit, documents
|
||||
- `events/` — Bus singleton, 36 event types, event log handler
|
||||
- `auth/` — API keys, require-auth/write, MFA, OAuth codes, invite tokens, cron, BankID
|
||||
- `supabase/` — Clients, middleware, `fetchAllRows` pagination
|
||||
- `api/` — Zod validation (`validateBody`/`validateQuery`), schemas
|
||||
- `reports/` — 20 report generators
|
||||
- `invoices/` — Matching, payment log, reminders, VAT rules, PDF
|
||||
- `transactions/` — `ingest.ts`, AI suggestions
|
||||
- `import/` — SIE, bank file, opening balance, account mapper
|
||||
- `documents/` — Matchers (single + batch)
|
||||
- `extensions/` — Registry, loader, context factory
|
||||
- `email/` — Service interface, Resend, templates
|
||||
- `company/` — Context resolution, CRUD, fiscal period computation
|
||||
- `providers/` — Fortnox, Bokio, Briox, BL, Visma (OAuth, retry, consent)
|
||||
- `salary/` — Payroll engine, tax tables, AGI, KU, payslips, löneväxling, personnummer
|
||||
- `processing-history/`, `reconciliation/`, `tax/`, `vat/` (VIES, MOMS box), `deadlines/`, `currency/` (Riksbanken), `skatteverket/`, `bankgiro/` (Luhn), `calendar/` (ICS)
|
||||
- `errors/` — Swedish error mapping (Zod → Postgres → HTTP → fallback)
|
||||
- `rate-limits/` — Postgres-backed `checkInboxUploadRateLimit` via `check_and_increment_inbox_quota` RPC; fails open
|
||||
- `hooks/`, `logger.ts`, `support.ts`, `utils.ts` (`cn()`, `formatCurrency()`, `formatDate()`, `formatOrgNumber()`)
|
||||
|
||||
---
|
||||
|
||||
## App Routes
|
||||
|
||||
**Pages**: `/login`, `/register`, `/reset-password`, `/mfa/{enroll,verify}`, `/onboarding`, `/companies/new`, `/invite/[token]`, `/` (dashboard), `/transactions`, `/invoices[/new|/[id]|/[id]/credit]`, `/supplier-invoices[/new|/[id]]`, `/customers[/[id]]`, `/suppliers[/[id]]`, `/expenses[/new|/[id]]`, `/receipts[/scan]`, `/bookkeeping[/[id]|/year-end]`, `/salary[/employees|/runs]`, `/reports`, `/import`, `/kpi`, `/deadlines`, `/pending`, `/help`, `/extensions[/[sector]/[ext]]`, `/e/[sector]/[slug]` (workspace), `/settings/*`, `/dpa`, `/privacy`, `/invoice-action/[token]`, `/sandbox`.
|
||||
|
||||
**API endpoints**:
|
||||
- `/api/bookkeeping/*` — accounts, fiscal periods, journal entries (CRUD/reverse/correct), mapping rules, voucher gaps
|
||||
- `/api/invoices/*`, `/api/supplier-invoices/*` — CRUD + state transitions
|
||||
- `/api/transactions/*` — categorize, describe, book, match-{invoice,supplier-invoice}, batch, AI suggestions
|
||||
- `/api/customers/*`, `/api/suppliers/*` — CRUD
|
||||
- `/api/documents/*` — CRUD, versions, link, match-sweep, verify cron
|
||||
- `/api/reports/*` — 19 endpoints (GL, TB, BS, IS, AR/supplier ledger, VAT, SIE, INK2, NE-bilaga, KPI, audit, continuity, monthly, full-archive, salary, vacation, avgifter)
|
||||
- `/api/salary/*` — employees, payroll-config, tax-tables, KU, runs
|
||||
- `/api/import/*` — bank-file, SIE (parse/execute/mappings)
|
||||
- `/api/reconciliation/bank/*`, `/api/settings/*`, `/api/company/*`, `/api/team/*`
|
||||
- `/api/deadlines/*`, `/api/tax-deadlines/*` — CRUD + crons
|
||||
- `/api/pending-operations/*`, `/api/events/*`, `/api/audit-trail/*`
|
||||
- `/api/calendar/feed/[token]`, `/api/mcp-oauth/*`, `/api/support/contact`, `/api/account/delete`
|
||||
- `/api/log`, `/api/health`, `/api/vat/validate`, `/api/currency/rate`, `/api/sandbox/*`
|
||||
- `/api/extensions/ext/[...path]` — dynamic extension routes
|
||||
Tool authoring conventions, the staged-operation completion-signal pattern, and OAuth details are in `.claude/rules/mcp-server.md`.
|
||||
|
||||
---
|
||||
|
||||
@@ -243,262 +144,53 @@ export async function POST(request: Request) {
|
||||
|
||||
**Framework**: Vitest 4, `node` env, tests in `__tests__/`. Scope: `lib/` and `app/api/`. No component/E2E tests.
|
||||
|
||||
**Helpers** (`tests/helpers.ts`): `createMockSupabase()`, `createQueuedMockSupabase()`, `createMockRequest()`, `parseJsonResponse()`, `createMockRouteParams()`, plus fixture factories (`makeTransaction`, `makeJournalEntry`, `makeInvoice`, `makeCustomer`, `makeSupplier`, `makeSupplierInvoice`, `makeFiscalPeriod`, `makeReceipt`, `makeDocumentAttachment`, `makeCompany`, `makeCompanySettings`, `makeTaxCode`, `makeSIEVoucher`, `makeBankConnection`, etc.).
|
||||
**Helpers** (`tests/helpers.ts`): `createMockSupabase()`, `createQueuedMockSupabase()`, `createMockRequest()`, `parseJsonResponse()`, `createMockRouteParams()`, plus fixture factories (`makeTransaction`, `makeJournalEntry`, `makeInvoice`, `makeCustomer`, `makeSupplier`, `makeSupplierInvoice`, `makeFiscalPeriod`, etc.).
|
||||
|
||||
**Patterns**: Always mock `@/lib/supabase/server`. `vi.clearAllMocks()` + `eventBus.clear()` in `beforeEach`. Test auth (401), validation (400), 404, 500, happy path.
|
||||
|
||||
**pg-real**: Parallel Vitest project for triggers/RPCs/RLS using real Postgres (CI: `supabase/postgres:15`, migrations replayed). Local: `npm run test:pg`. File convention `*.pg.test.ts`. Helpers: `tests/pg/setup.ts` (`getPool()`, `withUserContext()`), `tests/pg/fixtures.ts` (`seedCompany()`, `insertDraftJournalEntry()`, etc.). **Required**: any PR touching a trigger/RPC/RLS/DEFERRABLE must include or extend a `*.pg.test.ts`.
|
||||
|
||||
---
|
||||
|
||||
## Database & Migrations
|
||||
|
||||
**Location**: `supabase/migrations/` — 118 files. Early migrations use sequential numbering (`20240101000001`–`20240101000038`), later ones use real timestamps.
|
||||
|
||||
### Key Tables (~60)
|
||||
|
||||
- **Multi-tenant**: `companies`, `company_members`, `company_invitations`, `teams`, `team_members`, `team_invitations`, `user_preferences`, `profiles`
|
||||
- **Bookkeeping**: `chart_of_accounts`, `fiscal_periods`, `journal_entries`, `journal_entry_lines`, `account_balances`, `voucher_sequences`, `voucher_gap_explanations`
|
||||
- **Invoicing**: `customers`, `invoices`, `invoice_items`, `invoice_payments`, `invoice_inbox_items`
|
||||
- **Suppliers**: `suppliers`, `supplier_invoices`, `supplier_invoice_items`
|
||||
- **Banking**: `bank_connections`, `transactions`, `bank_file_imports`, `payment_match_log`
|
||||
- **Documents**: `document_attachments` (WORM), `receipts`, `receipt_line_items`
|
||||
- **Settings**: `company_settings`, `mapping_rules`, `categorization_templates`, `booking_template_library`, `extension_data`
|
||||
- **Dimensions**: `cost_centers`, `projects`
|
||||
- **Tax/Deadlines**: `tax_rates`, `tax_table_rates`, `deadlines`, `calendar_feeds`, `skatteverket_tokens`
|
||||
- **API/Auth**: `api_keys`, `oauth_used_codes`, `bankid_identities`
|
||||
- **Audit/Ops**: `audit_log` (immutable), `event_log` (30d TTL), `pending_operations`, `processing_history`, `ai_usage_tracking`, `automation_webhooks`
|
||||
- **Inbox**: `invoice_inbox_items`, `company_inboxes`, `email_connections`
|
||||
- **Salary**: `employees`, `salary_runs`, `salary_run_employees`, `salary_line_items`, `salary_payroll_config`, `agi_declarations`
|
||||
- **Providers**: `provider_consents`, `provider_consent_tokens`, `provider_otc`
|
||||
- **Other**: `sandbox_users`
|
||||
|
||||
### Key RPC Functions
|
||||
|
||||
- `create_company_with_owner()` — Atomic company + owner creation
|
||||
- `commit_journal_entry()` — Atomic draft→posted with voucher number
|
||||
- `next_voucher_number()` — Concurrent-safe voucher generation
|
||||
- `detect_voucher_gaps()` — BFNAR 2013:2 gap detection
|
||||
- `generate_invoice_number()`, `get_next_arrival_number()`, `generate_delivery_note_number()` — Sequence generators
|
||||
- `seed_chart_of_accounts()` — BAS chart seeding per entity type
|
||||
- `validate_and_increment_api_key()` — Atomic rate limiting
|
||||
- `user_company_ids()` — RLS helper returning user's company IDs
|
||||
- `get_unlinked_1930_lines()` — Bank reconciliation helper
|
||||
- `cleanup_sandbox_user()`, `cleanup_expired_sandbox_users()` — Sandbox lifecycle
|
||||
|
||||
### Key Triggers
|
||||
|
||||
- `check_journal_entry_balance()` — Debit must equal credit
|
||||
- `enforce_journal_entry_immutability()` — Posted entries cannot be modified
|
||||
- `enforce_period_lock()` — No entries in closed/locked periods
|
||||
- `enforce_company_lock_date()` — Company-wide bookkeeping lock date
|
||||
- `block_document_deletion()` — WORM compliance
|
||||
- `enforce_retention_journal_entries()` — 7-year retention
|
||||
- `audit_log_immutable()` — Audit log cannot be modified
|
||||
- `write_audit_log()` — Auto-audit on DML operations
|
||||
- `sync_team_member_to_companies()` — Auto-sync team→company membership
|
||||
|
||||
### Migration Rules
|
||||
|
||||
1. Enable RLS + policies using `user_company_ids()` for company-scoped data
|
||||
2. Add `updated_at` trigger via `update_updated_at_column()`
|
||||
3. UUID PKs: `DEFAULT uuid_generate_v4()`
|
||||
4. Company ownership: `company_id UUID REFERENCES companies NOT NULL` + `user_id UUID REFERENCES auth.users ON DELETE CASCADE NOT NULL`
|
||||
5. Never modify existing migrations — create new ones
|
||||
6. Never modify enforcement triggers (migration 017) — legally required
|
||||
7. Apply via Supabase MCP `apply_migration`
|
||||
8. Always end with `NOTIFY pgrst, 'reload schema'` when altering table structure
|
||||
|
||||
**Agent skill bodies (`agent_atom_registry`)**: skill content is authored in `.claude/skills/**/SKILL.md` and inlined into the DB `body` column at runtime (not read from disk — that doesn't bundle on Vercel/Docker). After editing any SKILL.md, run `npm run skills:generate` to emit a new `*_seed_agent_atom_bodies.sql` migration and commit it; `npm run skills:check` (wired into CI) fails the build if you forget. The MCP server exposes only atoms with `mcp_exposed = true` (swarm-* audit skills are never atoms).
|
||||
**pg-real**: Parallel Vitest project for triggers/RPCs/RLS using real Postgres. File convention `*.pg.test.ts`. **Required**: any PR touching a trigger/RPC/RLS/DEFERRABLE must include or extend a `*.pg.test.ts`. (Details in `.claude/rules/database.md`.)
|
||||
|
||||
---
|
||||
|
||||
## Skills, Git & CI
|
||||
|
||||
**Skills**: Always use `/frontend-design` for new UI. Use `vercel:deploy` for deployment. Use `/supabase-migration` for new migrations. Use `/erp-api-route` for new API routes. Use `/create-extension` for new extensions. Use the Swedish domain skills (`swedish-sie-import-export`, `swedish-accounting-compliance`, `swedish-vat`, `swedish-invoice-compliance`, `swedish-payroll`, `swedish-year-end-closing`, `swedish-financial-reporting`, `swedish-sru-filing`, `swedish-asset-accounting`, `swedish-project-accounting`, `swedish-tax-planning`) for accounting domain questions.
|
||||
**Skills**: Use `/frontend-design` for new UI, `vercel:deploy` for deployment, `/supabase-migration` for new migrations, `/erp-api-route` for new API routes, `/create-extension` for new extensions. Use the Swedish domain skills (`swedish-vat`, `swedish-accounting-compliance`, `swedish-invoice-compliance`, `swedish-payroll`, `swedish-year-end-closing`, `swedish-sie-import-export`, `swedish-sru-filing`, `swedish-financial-reporting`, `swedish-asset-accounting`, `swedish-project-accounting`, `swedish-tax-planning`, `swedish-e-invoicing`) for accounting domain questions. The `swedish-*`, `industry/*`, and `modifier/*` skills also ship as product atoms (see `.claude/rules/database.md`).
|
||||
|
||||
**Git**: Conventional commits (`feat:`, `fix:`, `refactor:`, `test:`, `docs:`). Atomic commits, branch from `main`.
|
||||
|
||||
**CI**:
|
||||
- `.github/workflows/core-build.yml` — resets extensions to empty, runs build + test, verifies no core code imports from `@/extensions/` directly.
|
||||
- `.github/workflows/swedish-compliance-review.yml` — Swedish accounting compliance review on PRs touching bookkeeping/reports/tax logic.
|
||||
- `.github/workflows/docker-publish.yml` — pushes images to GHCR on main.
|
||||
|
||||
**Docker** (`.github/workflows/docker-publish.yml`): Pushes to GHCR (`erp-mafia/erp-base`) on main push. 4-stage Dockerfile (base → deps → builder → runner) with Node 22 Alpine. Runtime env placeholder replacement via `docker-entrypoint.sh`. Docker Compose with app + supercronic cron service.
|
||||
- `.github/workflows/docker-publish.yml` — pushes images to GHCR (`erp-mafia/erp-base`) on main.
|
||||
|
||||
---
|
||||
|
||||
## Deployment
|
||||
|
||||
### Vercel (Hosted)
|
||||
- **Vercel (hosted)**: Cron jobs in `vercel.json` (deadline status, invoice reminders, tax deadlines, enable-banking sync, document verify, sandbox cleanup, event log cleanup, cloud-backup auto-sync).
|
||||
- **Docker (self-hosted)**: 4-stage Node 22 Alpine `Dockerfile` (standalone output) + `docker-compose.yml` (app + supercronic cron). `docker-entrypoint.sh` validates env vars and replaces build-time placeholders in `.next/static/`. Extension presets: `docker/extensions.{self-hosted,hosted}.json`.
|
||||
|
||||
Cron jobs in `vercel.json`: deadline status (`6:00`), invoice reminders (`8:00`), tax deadlines (yearly Jan 2), enable-banking sync (`5:00`), document verify (`3:00`), sandbox cleanup (`4:00`), event log cleanup (`2:00`, 30-day TTL), cloud-backup auto-sync (hourly).
|
||||
**Environment variables**:
|
||||
- **Required**: `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_ANON_KEY`, `SUPABASE_SERVICE_ROLE_KEY`, `NEXT_PUBLIC_APP_URL`, `CRON_SECRET`
|
||||
- **Auth**: `NEXT_PUBLIC_REQUIRE_MFA` (set `true` on hosted), `NEXT_PUBLIC_SELF_HOSTED` (set `true` for Docker)
|
||||
- **Extension-specific** (only when enabled): `ENABLE_BANKING_APP_ID`/`ENABLE_BANKING_APP_KEY`, `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `RESEND_API_KEY`, `VAPID_PUBLIC_KEY`/`VAPID_PRIVATE_KEY`
|
||||
- **Optional**: `SENTRY_DSN`, `SENTRY_AUTH_TOKEN`
|
||||
|
||||
### Docker (Self-Hosted)
|
||||
---
|
||||
|
||||
- `Dockerfile`: 4-stage Node 22 Alpine build with standalone output
|
||||
- `docker-compose.yml`: App service + supercronic cron scheduler
|
||||
- `docker-entrypoint.sh`: Validates required env vars, replaces build-time placeholders in `.next/static/` JS
|
||||
- Extension presets: `docker/extensions.self-hosted.json`, `docker/extensions.hosted.json`
|
||||
## Path-scoped rules (`.claude/rules/`)
|
||||
|
||||
### Environment Variables
|
||||
Topic detail loads automatically when Claude touches matching files:
|
||||
|
||||
**Required**: `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_ANON_KEY`, `SUPABASE_SERVICE_ROLE_KEY`, `NEXT_PUBLIC_APP_URL`, `CRON_SECRET`
|
||||
- `design.md` — design context & locked design-system tokens (`app/**`, `components/**`)
|
||||
- `i18n.md` — bilingual sv/en conventions + "stays Swedish" surfaces (UI + `lib/email|invoices|reports|salary`)
|
||||
- `api-routes.md` — API route pattern + endpoint map (`app/api/**`)
|
||||
- `database.md` — migration rules, key tables/RPCs/triggers, `agent_atom_registry` (`supabase/migrations/**`)
|
||||
- `mcp-server.md` — MCP tool authoring conventions (`extensions/general/mcp-server/**`)
|
||||
- `bookkeeping.md` — BAS accounts, VAT treatments/rutor, `lib/core/` services (`lib/bookkeeping|core|reports|vat|invoices|salary`)
|
||||
|
||||
**Auth**: `NEXT_PUBLIC_REQUIRE_MFA` (set `true` on hosted), `NEXT_PUBLIC_SELF_HOSTED` (set `true` for Docker)
|
||||
|
||||
**Extension-specific** (only when extension is enabled): `ENABLE_BANKING_APP_ID`/`ENABLE_BANKING_APP_KEY`, `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `RESEND_API_KEY`, `VAPID_PUBLIC_KEY`/`VAPID_PRIVATE_KEY`
|
||||
|
||||
**Optional**: `SENTRY_DSN`, `SENTRY_AUTH_TOKEN`
|
||||
---
|
||||
|
||||
## Other
|
||||
Never create a NUL/nul file: \gnubok\NUL
|
||||
|
||||
---
|
||||
|
||||
## i18n
|
||||
|
||||
The app is Swedish-first and bilingual (Swedish + English) for UI chrome. Locale is per-user on `user_preferences.locale` (`'sv' | 'en'`, default `'sv'`), resolved server-side via next-intl. The user picker lives at `/settings/account`.
|
||||
|
||||
**Pattern for new UI:**
|
||||
|
||||
```tsx
|
||||
// Server component
|
||||
import { getTranslations } from 'next-intl/server'
|
||||
const t = await getTranslations('namespace')
|
||||
|
||||
// Client component
|
||||
'use client'
|
||||
import { useTranslations } from 'next-intl'
|
||||
const t = useTranslations('namespace')
|
||||
|
||||
// In JSX
|
||||
<button>{t('save')}</button>
|
||||
```
|
||||
|
||||
Add new strings to both `messages/sv.json` and `messages/en.json` under the matching namespace (`common`, `nav`, `auth`, `settings`, `empty`, etc.). Never ship an English key without a Swedish counterpart — Swedish is the default and the fallback.
|
||||
|
||||
**Locale-aware formatters:**
|
||||
- `formatCurrency(amount)` — stays SEK with sv-SE conventions in BOTH locales (Swedish accounting standard, not a UI string).
|
||||
- `formatDate(date)` — ISO `yyyy-MM-dd`, locale-independent.
|
||||
- `formatDateLong(date, locale)` — accepts locale. In client components use `useFormat()` (`lib/hooks/use-format.ts`) which pulls the active locale.
|
||||
|
||||
**Error messages:** `getErrorMessage(err, { locale, context })` from `lib/errors/get-error-message.ts` is bilingual on the primary maps (Postgres codes, HTTP statuses, context fallbacks, generic fallback). The structured error envelope (`{ error: { code, message, message_en } }`) already carries both; the function picks the right one from `locale`. Pass `useLocale()` / `getLocale()` as the locale arg.
|
||||
|
||||
**Stays Swedish — do NOT translate:**
|
||||
|
||||
| Surface | Reason |
|
||||
|---|---|
|
||||
| Invoice PDFs (`lib/invoices/pdf-template.tsx`) | Customer-facing — driven by `customer.language` (`sv` default, `en` opt-in). The template's chrome translates; statutory chapter refs (ML 17 kap 24§, ML 3 kap.) stay intact in both locales. |
|
||||
| Customer email templates (`lib/email/invoice-templates.ts`, `reminder-templates.ts`) | Same — `customer.language` drives the output. `reminder-templates.ts` is still Swedish-only; mirror the PDF/invoice-templates approach if you add English here. |
|
||||
| Year-end wizard (`app/(dashboard)/bookkeeping/year-end/page.tsx`) | Statutory bokslut terminology; English would be misleading |
|
||||
| Journal entry editor (`app/(dashboard)/bookkeeping/[id]/page.tsx`) | Deeply regulatory (verifikat, voucher numbers, BAS) |
|
||||
| INK2 / NE-bilaga / SRU (`lib/reports/ink2/**`, `lib/reports/ne-bilaga/**`, `lib/reports/sru-*`) | Skatteverket forms — field codes and labels are statutory |
|
||||
| SIE export (`lib/reports/sie-export.ts`) | SIE format is Swedish-only by spec (#KONTO, #VER, etc.) |
|
||||
| BAS chart names (`lib/bookkeeping/bas-data/**`) | Standardized Swedish account names per BAS 2026 |
|
||||
| VAT declaration ruta labels (`lib/reports/vat-declaration*.ts`) | Momsdeklaration field labels are Skatteverket form labels |
|
||||
| Salary AGI / KU (`lib/salary/agi*`, `lib/salary/ku*`) | Skatteverket-bound forms |
|
||||
| Bookkeeping engine domain errors ("Verifikationen balanserar inte", "Bokföringen är låst") | Regulatory concepts; English equivalents would be ambiguous |
|
||||
|
||||
Anything in the table above stays Swedish in BOTH locales. If you find yourself reaching for `t()` inside one of these files, stop and reconsider.
|
||||
|
||||
---
|
||||
|
||||
## Design Context
|
||||
|
||||
### Users
|
||||
|
||||
Swedish sole traders (enskild firma) and small business owners (aktiebolag) who need to manage their own bookkeeping. They are not accountants — they are professionals (consultants, freelancers, shop owners) who want to stay compliant without hiring one. They use gnubok in short, focused sessions: sending an invoice, categorizing bank transactions, filing a VAT declaration. Speed and clarity matter — every second spent in the app is a second away from their real work.
|
||||
|
||||
### Brand & Aesthetic
|
||||
|
||||
**Editorial monochrome.** Paper-white surfaces, hairline borders, serif headlines. The interface should feel like a well-made instrument — considered, quiet, confident. Anti-references: enterprise software (SAP/Oracle density), neon SaaS coldness.
|
||||
|
||||
- **Palette**: Achromatic foundation. Pure white background, warm beige (`40 11% 89%`) for chips / active sidebar / hover / secondary buttons. Achromatic primary (no cool tint). Semantic colors (`--success` sage, `--warning` ochre, `--destructive` terracotta) exist but are **data-only** — they appear in charts and financial numbers (positive/negative deltas), never as chrome backgrounds. In chrome, only `--destructive` survives.
|
||||
- **Typography**: Hedvig Letters Serif for display headings, Geist (sans) for body, forms, and tables. Hedvig is single-weight (400) — do not apply `font-medium` to display text; its natural high-contrast strokes carry the weight. Tabular numbers everywhere financial data appears.
|
||||
- **Surfaces**: Cards sit flat on the page — no shadow, full-opacity hairline border (`border-border`), `rounded-lg` (8px). Card background matches page background; the border carries hierarchy. Dark mode drops the warm tint from secondary for a pure-gray mood shift; light mode keeps the beige.
|
||||
- **Spacing**: Generous whitespace. Dense data (tables, ledgers) uses tighter spacing but never feels cramped.
|
||||
- **Motion**: Functional, not decorative. No press-scale, no hover-lift, no spring overshoot. Hover state is a flat background shift (`bg-secondary/60`). `transition-colors duration-150` is the default. Stagger animations on list entry are fine. Respect `prefers-reduced-motion` (already wired).
|
||||
- **Icons**: Lucide — 15px in navigation, slightly larger in empty states.
|
||||
|
||||
### Design Principles
|
||||
|
||||
1. Clarity over cleverness — Swedish labels, obvious hierarchy.
|
||||
2. Earned minimalism — remove what doesn't serve the task, keep compliance context.
|
||||
3. Numbers are first-class — tabular-nums, alignment, positive/negative clarity.
|
||||
4. Trust through consistency.
|
||||
5. Speed is a feature — optimize for the 90-second session.
|
||||
|
||||
### Accessibility
|
||||
|
||||
WCAG AA (4.5:1 text, 3:1 UI). Keyboard-navigable + visible focus rings. Respect `prefers-reduced-motion`. Color never sole state indicator. Touch targets ≥40px (44px for mobile-critical). Icon-only buttons need `aria-label`.
|
||||
|
||||
### Design System Tokens
|
||||
|
||||
These conventions are locked. Don't reinvent them in new code; deviating from them on existing pages is a regression.
|
||||
|
||||
**Spacing scale.** Only use Tailwind values `1, 2, 3, 4, 6, 8, 10, 12`. **Forbidden:** `2.5`, `5`, hardcoded pixels in page logic.
|
||||
|
||||
| Token | Tailwind | Use for |
|
||||
|---|---|---|
|
||||
| 4 | `1` | icon padding |
|
||||
| 8 | `2` | tight inline gaps |
|
||||
| 12 | `3` | dense list rows, badge gaps |
|
||||
| 16 | `4` | default form / control / grid gap |
|
||||
| 24 | `6` | **card padding default** (`p-6`) |
|
||||
| 32 | `8` | **between page sections** (`space-y-8` on page root) |
|
||||
| 40 | `10` | hero spacing |
|
||||
| 48 | `12` | top of page after header |
|
||||
|
||||
Compact metric cards (e.g. dashboard tiles, salary KPI row) use `p-4`. Detail cards use `p-6`. Never mix `p-5`.
|
||||
|
||||
**Layout.**
|
||||
- Sidebar width: `md:w-64` (256px). Main content offset: `md:pl-64`.
|
||||
- Main container: `max-w-5xl mx-auto px-5 py-8 md:px-8 md:py-10` (via `components/dashboard/MainContainer.tsx`).
|
||||
- Page root: `<div className="space-y-8">`.
|
||||
|
||||
**Primitives — always use these, don't hand-roll.**
|
||||
|
||||
| Need | Component | Notes |
|
||||
|---|---|---|
|
||||
| Page title + action | `components/ui/page-header.tsx` `PageHeader` | Use this, not bespoke `<h1>` + `<p>` blocks. Drop the `description` prop when it just paraphrases the title. |
|
||||
| Data table | `components/ui/table.tsx` `Table / TableHeader / TableHead / TableRow / TableCell` | Header style is baked in: `text-[11px] font-medium uppercase tracking-wider text-muted-foreground`. Wrap in `<CardContent className="p-0">` when the table is a card's primary content. Add `tabular-nums` to numeric cells. |
|
||||
| Status indicator | `components/ui/badge.tsx` `<Badge variant>` | Variants: `default / secondary / success / warning / destructive / outline`. **Never** use raw Tailwind colors (`bg-blue-100`, `bg-emerald-500/10`, etc.) for status. Map status → variant via a small `Record` per feature. |
|
||||
| No-data state | `components/ui/empty-state.tsx` `EmptyState` | Don't hand-roll `<div className="flex flex-col items-center py-12">…</div>`. Preset variants exist (`EmptyInvoices`, `EmptyCustomers`, `EmptyTransactions`, etc.). |
|
||||
| Loading placeholder | `components/ui/skeleton.tsx` `<Skeleton>` | Don't hand-roll `bg-muted rounded animate-pulse` divs. |
|
||||
| Inline help / formulas | `components/ui/info-tooltip.tsx` `InfoTooltip` | Hover-revealed; don't use always-visible info buttons. |
|
||||
| Fiscal year picker | `components/common/FiscalYearSelector.tsx` | Don't use raw `<select>` for fiscal periods. |
|
||||
|
||||
**Tabular display rules.**
|
||||
- All financial values get `tabular-nums`.
|
||||
- Dates in tables: `tabular-nums` for fixed width.
|
||||
- Right-align numeric columns (`text-right`).
|
||||
- For group bands inside tables (Resultatrapport-style): `<tr className="bg-muted/30"><td colSpan={n} className="px-4 py-2 text-[12px] font-semibold text-muted-foreground">{label}</td></tr>`.
|
||||
|
||||
**Date formatting.** Two helpers in `lib/utils.ts`:
|
||||
- `formatDate(x)` → `2026-05-11` (ISO `yyyy-MM-dd`). Use for accounting data — transaction dates, invoice dates, payment dates, voucher dates. Aligns in tables, matches SIE/BFL convention.
|
||||
- `formatDateLong(x)` → `11 maj 2026` (Swedish long form). Use for metadata — when something was created, linked, verified, expires. Settings panels and audit displays.
|
||||
|
||||
Never render raw `{x.invoice_date}` directly — always route through `formatDate()` for code consistency.
|
||||
|
||||
**Currency.** `formatCurrency(n, currency?)` from `lib/utils.ts`. Default SEK.
|
||||
|
||||
**Typography.**
|
||||
- Page title: use `PageHeader` (renders `font-display text-3xl md:text-4xl tracking-tight`). Do not hand-roll an `<h1>`.
|
||||
- Card title: `<CardTitle className="text-base">` for sections, default for primary cards. The primitive already drops `font-medium` — do not add it back.
|
||||
- Section divider header inside a page: `<h2 className="text-sm font-medium uppercase tracking-wider text-muted-foreground">`.
|
||||
- Headline number: `font-display text-xl tabular-nums`. No `font-medium` — Hedvig's natural weight carries the gravitas.
|
||||
- Display font (`font-display`, Hedvig Letters Serif) reserved for h1/h2/h3 and primary financial numbers. If a specific `font-display` numeral reads weak inside a compact metric card, override that call site with `font-sans tabular-nums` (Geist) — better legibility on small numerals.
|
||||
|
||||
**Forbidden / dead patterns.**
|
||||
- Page descriptions that paraphrase the page title (e.g. `<PageHeader title="Fakturor" description="Hantera dina fakturor">`) → drop the description.
|
||||
- Two different status indicators on the same element (e.g. colored card border *and* Badge for status) → pick one (prefer Badge).
|
||||
- Mobile-specific `<select>` duplicating desktop tabs in code — use a single Tabs primitive or a single grouped `Select`.
|
||||
- Hand-rolled icon buttons smaller than `h-10 w-10`. Use shadcn `Button size="icon"`.
|
||||
- Color-coded status using full-rainbow Tailwind palette (`bg-amber-100`, `bg-emerald-500/10`, etc.). Use Badge variants tied to the brand palette.
|
||||
- `shadow-sm` / `shadow-md` / `shadow-lg` on cards, buttons, or list items. The aesthetic is flat-with-hairlines — surfaces use `border-border`, not elevation. Shadows survive only on dialogs/popovers/dropdowns (anything that overlays the page).
|
||||
- `active:scale-[...]` on buttons. Buttons do not bounce.
|
||||
- `bg-gradient-to-*` on page or card backgrounds. Flat surfaces only.
|
||||
- `font-medium` on display elements (`font-display`, h1/h2/h3, CardTitle, PageHeader title). Hedvig is single-weight by design.
|
||||
- `rounded-xl` (12px) on cards. Cards are `rounded-lg` (8px). `rounded-xl` survives only on prominent hero-style surfaces if absolutely needed.
|
||||
- Opacity-suffixed border classes (`border-border/30`, `border-border/60`) on cards and primary surfaces. Use full-opacity `border-border` — the new border token is calibrated for that.
|
||||
Never create a NUL/nul file: `\Accounted\NUL`.
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
# Contributing to gnubok
|
||||
# Contributing to Accounted
|
||||
|
||||
Thank you for your interest in contributing to gnubok. This guide covers the development workflow, coding standards, and submission process.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Self-Hosting gnubok with Docker
|
||||
# Self-Hosting Accounted with Docker
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -14,7 +14,7 @@ You do **not** need Node.js, npm, or anything else installed locally. The pre-bu
|
||||
### 1. Download the required files
|
||||
|
||||
```bash
|
||||
mkdir gnubok && cd gnubok
|
||||
mkdir Accounted && cd Accounted
|
||||
|
||||
# Compose file + env template
|
||||
curl -fsSLO https://raw.githubusercontent.com/gnubok/gnubok/main/docker-compose.yml
|
||||
@@ -41,7 +41,7 @@ Open `.env` and fill in the **required** values:
|
||||
| `NEXT_PUBLIC_SUPABASE_URL` | Supabase dashboard → Settings → API → Project URL |
|
||||
| `NEXT_PUBLIC_SUPABASE_ANON_KEY` | Supabase dashboard → Settings → API → `anon` `public` key |
|
||||
| `SUPABASE_SERVICE_ROLE_KEY` | Supabase dashboard → Settings → API → `service_role` key |
|
||||
| `NEXT_PUBLIC_APP_URL` | The URL where you'll access gnubok (e.g. `https://gnubok.example.com`) |
|
||||
| `NEXT_PUBLIC_APP_URL` | The URL where you'll access Accounted (e.g. `https://gnubok.example.com`) |
|
||||
| `CRON_SECRET` | Any random string — `openssl rand -hex 32` works |
|
||||
|
||||
Once `.env` is filled in, **restrict its permissions** so other users on the host can't read your service-role key or cron secret:
|
||||
@@ -171,7 +171,7 @@ If you prefer to build locally instead of pulling the pre-built image:
|
||||
```bash
|
||||
# Clone the repo
|
||||
git clone https://github.com/gnubok/gnubok.git
|
||||
cd gnubok
|
||||
cd Accounted
|
||||
cp .env.docker.example .env
|
||||
# Fill in .env
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# gnubok
|
||||
# Accounted
|
||||
|
||||
Open-source Swedish accounting software for sole traders (enskild firma) and limited companies (aktiebolag).
|
||||
|
||||
[](LICENSE)
|
||||
|
||||
## What is gnubok?
|
||||
## What is Accounted?
|
||||
|
||||
gnubok implements double-entry bookkeeping compliant with Swedish accounting law (Bokforingslagen). It supports the BAS 2026 chart of accounts, handles VAT declarations (momsdeklaration), SIE import/export, and enforces 7-year document retention. Built for sole traders and limited companies operating in Sweden.
|
||||
Accounted implements double-entry bookkeeping compliant with Swedish accounting law (Bokforingslagen). It supports the BAS 2026 chart of accounts, handles VAT declarations (momsdeklaration), SIE import/export, and enforces 7-year document retention. Built for sole traders and limited companies operating in Sweden.
|
||||
|
||||
## Features
|
||||
|
||||
@@ -24,7 +24,7 @@ gnubok implements double-entry bookkeeping compliant with Swedish accounting law
|
||||
|
||||
```bash
|
||||
git clone https://github.com/erp-mafia/gnubok.git
|
||||
cd gnubok
|
||||
cd Accounted
|
||||
./setup.sh # Prompts for Supabase credentials, generates .env
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
|
||||
## Reporting Vulnerabilities
|
||||
|
||||
If you discover a security vulnerability in gnubok, please report it responsibly. **Do not open a public issue.**
|
||||
If you discover a security vulnerability in Accounted, please report it responsibly. **Do not open a public issue.**
|
||||
|
||||
Email: **security@arcim.io**
|
||||
|
||||
|
||||
+5
-5
@@ -1,6 +1,6 @@
|
||||
# Self-Hosting gnubok
|
||||
# Self-Hosting Accounted
|
||||
|
||||
This guide walks you through deploying gnubok on your own infrastructure using Docker.
|
||||
This guide walks you through deploying Accounted on your own infrastructure using Docker.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -22,7 +22,7 @@ In the Supabase dashboard under **Authentication > URL Configuration**:
|
||||
1. Set **Site URL** to your deployment URL (e.g., `https://gnubok.example.com`).
|
||||
2. Add `https://gnubok.example.com/auth/callback` to the **Redirect URLs** allowlist.
|
||||
|
||||
gnubok uses email + password authentication with magic link as a fallback. The default Supabase email auth settings work out of the box. For production, configure a custom SMTP provider under **Authentication > SMTP Settings** to avoid Supabase's built-in rate limits.
|
||||
Accounted uses email + password authentication with magic link as a fallback. The default Supabase email auth settings work out of the box. For production, configure a custom SMTP provider under **Authentication > SMTP Settings** to avoid Supabase's built-in rate limits.
|
||||
|
||||
MFA (two-factor authentication via TOTP) is **not enforced** for self-hosted deployments — the Docker image sets `NEXT_PUBLIC_SELF_HOSTED=true` by default, which disables MFA enforcement. Users can still optionally enable 2FA in Settings > Säkerhet if they wish.
|
||||
|
||||
@@ -66,7 +66,7 @@ These are all available on Supabase hosted. `pg_cron` requires a paid plan — i
|
||||
|
||||
```bash
|
||||
git clone https://github.com/erp-mafia/gnubok.git
|
||||
cd gnubok
|
||||
cd Accounted
|
||||
./setup.sh
|
||||
```
|
||||
|
||||
@@ -76,7 +76,7 @@ The script checks prerequisites, prompts for your Supabase credentials, auto-gen
|
||||
|
||||
```bash
|
||||
git clone https://github.com/erp-mafia/gnubok.git
|
||||
cd gnubok
|
||||
cd Accounted
|
||||
cp .env.docker.example .env
|
||||
```
|
||||
|
||||
|
||||
+3
-3
@@ -1,6 +1,6 @@
|
||||
# Whitelabel fork checklist
|
||||
|
||||
gnubok is whitelabel-friendly: every user-visible brand reference reads from a single `BrandingService` (`lib/branding/service.ts`). If you don't override anything, the app behaves exactly like upstream gnubok. To run your own brand on top of gnubok, fork the repo and override the values you care about.
|
||||
Accounted is whitelabel-friendly: every user-visible brand reference reads from a single `BrandingService` (`lib/branding/service.ts`). If you don't override anything, the app behaves exactly like upstream gnubok. To run your own brand on top of Accounted, fork the repo and override the values you care about.
|
||||
|
||||
## Quick start
|
||||
|
||||
@@ -33,7 +33,7 @@ All branding can be set via env vars. Public ones use `NEXT_PUBLIC_BRANDING_*` (
|
||||
|
||||
| Env var | Field | Default |
|
||||
|---|---|---|
|
||||
| `NEXT_PUBLIC_BRANDING_APP_NAME` | `appName` | `Gnubok` |
|
||||
| `NEXT_PUBLIC_BRANDING_APP_NAME` | `appName` | `Accounted` |
|
||||
| `NEXT_PUBLIC_BRANDING_APP_DESCRIPTION` | `appDescription` | `Ekonomihantering` |
|
||||
| `BRANDING_LEGAL_ENTITY` | `legalEntity` | `Arcim` |
|
||||
| `BRANDING_SUPPORT_EMAIL` | `supportEmail` | `support@gnubok.se` |
|
||||
@@ -152,7 +152,7 @@ jobs:
|
||||
gh pr create \
|
||||
--base main \
|
||||
--head "${{ steps.merge.outputs.branch }}" \
|
||||
--title "Sync from upstream gnubok" \
|
||||
--title "Sync from upstream Accounted" \
|
||||
--body "Automated weekly sync from \`erp-mafia/gnubok@main\`."
|
||||
|
||||
- name: Report conflict
|
||||
|
||||
@@ -18,7 +18,7 @@ export default async function SelectCompanyPage() {
|
||||
redirect('/login')
|
||||
}
|
||||
|
||||
// Existing gnubok memberships.
|
||||
// Existing Accounted memberships.
|
||||
const { data: memberships } = await supabase
|
||||
.from('company_members')
|
||||
.select(`
|
||||
@@ -123,14 +123,14 @@ export default async function SelectCompanyPage() {
|
||||
(r) => r.positionEnd == null,
|
||||
)
|
||||
|
||||
// Drop TIC roles that already appear in the user's gnubok memberships —
|
||||
// those render via the "Your gnubok companies" section above instead.
|
||||
// Drop TIC roles that already appear in the user's Accounted memberships —
|
||||
// those render via the "Your Accounted companies" section above instead.
|
||||
const rolesNotAlreadyMine = activeRoles.filter(
|
||||
(r) => !memberOrgNumbers.has(r.companyRegistrationNumber.replace(/[\s-]/g, '')),
|
||||
)
|
||||
|
||||
// Cross-reference remaining TIC org numbers against the global companies
|
||||
// table to detect "exists in gnubok, user not a member" cases. Use the
|
||||
// table to detect "exists in Accounted, user not a member" cases. Use the
|
||||
// service client — RLS filters out companies the user isn't a member of,
|
||||
// which is exactly the data we need. Scoped to the specific org numbers.
|
||||
let externallyOwnedOrgs = new Set<string>()
|
||||
|
||||
+81
-17
@@ -12,20 +12,20 @@ export function generateMetadata(): Metadata {
|
||||
export default function DPAPage() {
|
||||
const { appName, legalEntity, privacyEmail } = getBranding()
|
||||
return (
|
||||
<div className="min-h-screen bg-gradient-to-b from-slate-50 to-white py-12 px-4">
|
||||
<div className="max-w-3xl mx-auto space-y-6">
|
||||
<div className="text-center mb-8">
|
||||
<h1 className="text-3xl font-bold text-gray-900 mb-2">
|
||||
<div className="min-h-screen bg-background py-12 px-4">
|
||||
<div className="max-w-3xl mx-auto space-y-8">
|
||||
<div className="text-center space-y-2">
|
||||
<h1 className="font-display text-3xl md:text-4xl tracking-tight text-foreground">
|
||||
Personuppgiftsbitradesavtal (DPA)
|
||||
</h1>
|
||||
<p className="text-muted-foreground">
|
||||
Enligt GDPR Art. 28 | Senast uppdaterad: 2026-06-01
|
||||
<p className="text-sm text-muted-foreground">
|
||||
Enligt GDPR Art. 28 · Senast uppdaterad: 2026-06-03
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>1. Roller</CardTitle>
|
||||
<CardTitle className="text-base">1. Roller</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
@@ -43,7 +43,26 @@ export default function DPAPage() {
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>2. Behandlingens syfte och omfattning</CardTitle>
|
||||
<CardTitle className="text-base">2. Behandling enligt instruktioner</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
Biträdet behandlar personuppgifter endast enligt den Ansvariges dokumenterade
|
||||
instruktioner, inklusive vid överföring av personuppgifter till tredjeland eller en
|
||||
internationell organisation, om inte unionsrätten eller svensk rätt ålägger Biträdet
|
||||
att göra det. I sådant fall informerar Biträdet den Ansvarige om det rättsliga kravet
|
||||
innan behandlingen sker, om inte sådan information är förbjuden enligt lag.
|
||||
</p>
|
||||
<p>
|
||||
Om Biträdet anser att en instruktion strider mot GDPR eller andra
|
||||
dataskyddsbestämmelser ska Biträdet omedelbart informera den Ansvarige.
|
||||
</p>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle className="text-base">3. Behandlingens syfte och omfattning</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>Biträdet behandlar personuppgifter för följande ändamål:</p>
|
||||
@@ -65,7 +84,21 @@ export default function DPAPage() {
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>3. Tekniska och organisatoriska åtgärder</CardTitle>
|
||||
<CardTitle className="text-base">4. Konfidentialitet</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
Biträdet säkerställer att de personer som har behörighet att behandla
|
||||
personuppgifterna har åtagit sig att iaktta konfidentialitet eller omfattas av en
|
||||
lämplig lagstadgad tystnadsplikt. Åtkomst till personuppgifter begränsas till personal
|
||||
som behöver uppgifterna för att fullgöra Biträdets åtaganden.
|
||||
</p>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle className="text-base">5. Tekniska och organisatoriska åtgärder</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>Biträdet vidtar följande åtgärder för att skydda personuppgifterna:</p>
|
||||
@@ -73,7 +106,10 @@ export default function DPAPage() {
|
||||
<li><strong>Kryptering:</strong> All data krypteras i transit (TLS 1.3) och i vila (AES-256)</li>
|
||||
<li><strong>Åtkomstkontroll:</strong> Row Level Security (RLS) säkerställer att varje användare
|
||||
enbart kan komma åt sina egna uppgifter</li>
|
||||
<li><strong>Autentisering:</strong> Säkra inloggningsmetoder (magic link, inga lösenord lagrade)</li>
|
||||
<li><strong>Autentisering:</strong> Inloggning med e-post och lösenord (lösenord lagras
|
||||
endast som saltad hash, aldrig i klartext), tvåfaktorsautentisering (2FA via TOTP)
|
||||
samt BankID (på den hostade tjänsten). Tvåfaktorsautentisering kan krävas för
|
||||
åtkomst</li>
|
||||
<li><strong>Integritetskontroll:</strong> SHA-256 checksummor för alla dokument, med
|
||||
regelbunden verifiering</li>
|
||||
<li><strong>Revisionslogg:</strong> Alla ändringshandelser loggas automatiskt av databasen
|
||||
@@ -82,7 +118,7 @@ export default function DPAPage() {
|
||||
raderas (databasutlösare)</li>
|
||||
<li><strong>Säkerhetskopior:</strong> Kontinuerliga databaskopior med point-in-time-recovery</li>
|
||||
<li><strong>EU-lagring och EU-inferens:</strong> All primär datalagring sker i EU
|
||||
(Supabase, eu-central-1). AI-inferens sker, när AI-funktioner är aktiverade, inom
|
||||
(Supabase, eu-north-1, Stockholm). AI-inferens sker, när AI-funktioner är aktiverade, inom
|
||||
EU via Amazon Bedrock (eu-north-1, Stockholm) — ingen överföring till tredje land</li>
|
||||
</ul>
|
||||
</CardContent>
|
||||
@@ -90,7 +126,7 @@ export default function DPAPage() {
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>4. Underbiträden</CardTitle>
|
||||
<CardTitle className="text-base">6. Underbiträden</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
@@ -105,12 +141,36 @@ export default function DPAPage() {
|
||||
Biträdet kommer att informera den Ansvarige minst 30 dagar i förväg innan
|
||||
en ny underbiträde anlitas, så att den Ansvarige har möjlighet att invända.
|
||||
</p>
|
||||
<p>
|
||||
Biträdet ålägger genom skriftligt avtal varje underbiträde samma
|
||||
dataskyddsskyldigheter som anges i detta avtal. Biträdet förblir fullt ansvarigt
|
||||
gentemot den Ansvarige för att underbiträdet fullgör sina skyldigheter.
|
||||
</p>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>5. Dataintrångsnotifiering</CardTitle>
|
||||
<CardTitle className="text-base">7. Bistånd med registrerades rättigheter</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
Biträdet bistår den Ansvarige, genom lämpliga tekniska och organisatoriska åtgärder
|
||||
och i den mån det är möjligt, med att fullgöra den Ansvariges skyldighet att besvara
|
||||
begäran från registrerade om utövande av sina rättigheter enligt GDPR kapitel III
|
||||
(art. 12–23), däribland rätt till tillgång, rättelse, radering, begränsning,
|
||||
dataportabilitet och invändning.
|
||||
</p>
|
||||
<p>
|
||||
Tjänsten tillhandahåller självbetjäningsfunktioner för export (SIE4, JSON, CSV) och
|
||||
radering som stöd för detta.
|
||||
</p>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle className="text-base">8. Dataintrångsnotifiering och bistånd enligt art. 32–36</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
@@ -125,15 +185,19 @@ export default function DPAPage() {
|
||||
<li>Åtgärder som vidtagits eller föreslås för att hantera incidenten</li>
|
||||
</ul>
|
||||
<p>
|
||||
Biträdet ska bistå den Ansvarige med den information som behövs för att den
|
||||
Ansvarige ska kunna uppfylla sin anmälningsplikt till IMY (Integritetsskyddsmyndigheten).
|
||||
Biträdet bistår den Ansvarige med att säkerställa att skyldigheterna enligt
|
||||
art. 32–36 i GDPR fullgörs, med beaktande av behandlingens art och den information
|
||||
som Biträdet har tillgång till. Detta omfattar säkerhet i behandlingen (art. 32),
|
||||
anmälan av personuppgiftsincidenter (art. 33–34), konsekvensbedömningar avseende
|
||||
dataskydd (art. 35, DPIA) samt förhandssamråd med Integritetsskyddsmyndigheten
|
||||
(IMY) (art. 36).
|
||||
</p>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>6. Revisionsrätt</CardTitle>
|
||||
<CardTitle className="text-base">9. Revisionsrätt</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
@@ -152,7 +216,7 @@ export default function DPAPage() {
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>7. Radering vid avslut</CardTitle>
|
||||
<CardTitle className="text-base">10. Radering vid avslut</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>
|
||||
|
||||
@@ -19,7 +19,7 @@ export default function PrivacyPolicyPage() {
|
||||
Integritetspolicy
|
||||
</h1>
|
||||
<p className="text-muted-foreground">
|
||||
Senast uppdaterad: 2026-06-01
|
||||
Senast uppdaterad: 2026-06-03
|
||||
</p>
|
||||
</div>
|
||||
|
||||
@@ -43,7 +43,7 @@ export default function PrivacyPolicyPage() {
|
||||
<CardContent className="prose prose-sm max-w-none">
|
||||
<p>Vi behandlar följande kategorier av personuppgifter:</p>
|
||||
<ul>
|
||||
<li><strong>Kontouppgifter:</strong> E-postadress (för inloggning via magic link)</li>
|
||||
<li><strong>Kontouppgifter:</strong> E-postadress (för inloggning)</li>
|
||||
<li><strong>Företagsuppgifter:</strong> Företagsnamn, organisationsnummer, adress, kontaktuppgifter</li>
|
||||
<li><strong>Bokföringsdata:</strong> Verifikationer, fakturor, kvitton, transaktioner, kontoplaner</li>
|
||||
<li><strong>Bankdata:</strong> Kontosaldon och transaktioner (via PSD2-koppling)</li>
|
||||
@@ -112,7 +112,7 @@ export default function PrivacyPolicyPage() {
|
||||
<tr className="border-b">
|
||||
<td className="py-2 pr-4 font-medium">Supabase</td>
|
||||
<td className="py-2 pr-4">Databas, autentisering, fillagring</td>
|
||||
<td className="py-2 pr-4">EU (eu-central-1)</td>
|
||||
<td className="py-2 pr-4">EU (eu-north-1, Stockholm)</td>
|
||||
<td className="py-2">EU-baserad lagring</td>
|
||||
</tr>
|
||||
<tr className="border-b">
|
||||
@@ -181,7 +181,7 @@ export default function PrivacyPolicyPage() {
|
||||
<p>
|
||||
Vissa underbiträden är baserade i USA. För dessa överföringar används EU-kommissionens
|
||||
standardavtalsklausuler (SCCs) som skyddsmekanism i enlighet med GDPR kapitel V.
|
||||
All primär datalagring (databas, filer) sker inom EU via Supabase (eu-central-1).
|
||||
All primär datalagring (databas, filer) sker inom EU via Supabase (eu-north-1, Stockholm).
|
||||
Även AI-inferens sker inom EU (Amazon Bedrock, eu-north-1) och innebär ingen
|
||||
överföring till tredje land.
|
||||
</p>
|
||||
|
||||
@@ -27,7 +27,7 @@ export async function GET(_request: Request) {
|
||||
summary: s.summary,
|
||||
tags: s.tags,
|
||||
/** MCP resource URI; load via the MCP server's resources/read with an authenticated key. */
|
||||
uri: `gnubok://skill/${s.slug}`,
|
||||
uri: `Accounted://skill/${s.slug}`,
|
||||
})),
|
||||
}
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ import { normalizeOrgNumber } from '@/lib/company-lookup/normalize-org-number'
|
||||
* GET /api/company/check-org-number?org_number=XXXXXXXXXX
|
||||
*
|
||||
* Returns `{ data: { exists: boolean } }` indicating whether the given
|
||||
* organisation number is already registered in any non-archived gnubok
|
||||
* organisation number is already registered in any non-archived Accounted
|
||||
* company. Used by the onboarding wizard to warn users before they try to
|
||||
* create a duplicate.
|
||||
*
|
||||
|
||||
@@ -53,6 +53,7 @@ export const POST = withRouteContext(
|
||||
payment_amount: outcome.result.paymentAmount,
|
||||
payment_id: outcome.result.paymentId,
|
||||
journal_entry_id: outcome.result.journalEntryId,
|
||||
reconciled_transaction_id: outcome.result.reconciledTransactionId,
|
||||
},
|
||||
})
|
||||
},
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
import { createClient } from '@/lib/supabase/server'
|
||||
import { NextResponse } from 'next/server'
|
||||
import { ensureInitialized } from '@/lib/init'
|
||||
import { validateBody } from '@/lib/api/validate'
|
||||
import { MarkOpeningBalanceSchema } from '@/lib/api/schemas'
|
||||
import { requireCompanyId } from '@/lib/company/context'
|
||||
import { requireWritePermission } from '@/lib/auth/require-write'
|
||||
|
||||
ensureInitialized()
|
||||
|
||||
/**
|
||||
* Re-tag a posted manual/import voucher on a bank account as an opening balance
|
||||
* (source_type='opening_balance') so bank reconciliation stops counting it as a
|
||||
* phantom difference. Delegates to the mark_entry_as_opening_balance RPC, which
|
||||
* enforces owner/admin role, the manual/import precondition, a bank-line check,
|
||||
* and the period lock. We only translate its errors to Swedish here.
|
||||
*/
|
||||
export async function POST(request: Request) {
|
||||
const supabase = await createClient()
|
||||
const { data: { user } } = await supabase.auth.getUser()
|
||||
|
||||
if (!user) {
|
||||
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
|
||||
}
|
||||
|
||||
const writeCheck = await requireWritePermission(supabase, user.id)
|
||||
if (!writeCheck.ok) return writeCheck.response
|
||||
|
||||
const companyId = await requireCompanyId(supabase, user.id)
|
||||
|
||||
const validation = await validateBody(request, MarkOpeningBalanceSchema)
|
||||
if (!validation.success) return validation.response
|
||||
const { journal_entry_id } = validation.data
|
||||
|
||||
const { data, error } = await supabase.rpc('mark_entry_as_opening_balance', {
|
||||
p_company_id: companyId,
|
||||
p_entry_id: journal_entry_id,
|
||||
})
|
||||
|
||||
if (error) {
|
||||
const raw = error.message || ''
|
||||
let message = 'Kunde inte markera verifikationen som ingående balans.'
|
||||
if (/owners and admins/i.test(raw)) {
|
||||
message = 'Endast ägare och administratörer kan markera en ingående balans.'
|
||||
} else if (/not found/i.test(raw)) {
|
||||
message = 'Verifikationen kunde inte hittas.'
|
||||
} else if (/manual\/import/i.test(raw)) {
|
||||
message = 'Bara manuellt eller importerat bokförda verifikationer kan markeras som ingående balans.'
|
||||
} else if (/posted entries/i.test(raw)) {
|
||||
message = 'Bara bokförda verifikationer kan markeras som ingående balans.'
|
||||
} else if (/bank\/cash account/i.test(raw)) {
|
||||
message = 'Verifikationen saknar rad på ett bankkonto (19xx) och kan inte vara en ingående balans.'
|
||||
} else if (/closed fiscal period/i.test(raw)) {
|
||||
message = 'Perioden är stängd. Öppna perioden innan du ändrar verifikationen.'
|
||||
} else if (/locked fiscal period/i.test(raw)) {
|
||||
message = 'Perioden är låst. Lås upp perioden innan du ändrar verifikationen.'
|
||||
}
|
||||
return NextResponse.json({ error: message }, { status: 400 })
|
||||
}
|
||||
|
||||
return NextResponse.json({ data })
|
||||
}
|
||||
@@ -53,6 +53,7 @@ export const POST = withRouteContext(
|
||||
payment_amount: outcome.result.paymentAmount,
|
||||
payment_id: outcome.result.paymentId,
|
||||
journal_entry_id: outcome.result.journalEntryId,
|
||||
reconciled_transaction_id: outcome.result.reconciledTransactionId,
|
||||
},
|
||||
})
|
||||
},
|
||||
|
||||
@@ -46,7 +46,7 @@ registerEndpoint({
|
||||
'Fetching balances — use the trial-balance report. Creating new accounts — this endpoint is read-only in v1 (use the dashboard).',
|
||||
pitfalls: [
|
||||
'account_number is a STRING — "1930", not 1930. The leading character can be 0 in non-BAS plans.',
|
||||
'is_system_account=true means the account was seeded by gnubok and cannot be archived or renamed.',
|
||||
'is_system_account=true means the account was seeded by Accounted and cannot be archived or renamed.',
|
||||
'Default filter excludes archived accounts; pass ?active=false to include them.',
|
||||
],
|
||||
example: {
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
/**
|
||||
* GET /api/v1/companies/{companyId}/compliance/check?type=...
|
||||
*
|
||||
* gnubok's defensible edge: a single, structured pre-flight endpoint that
|
||||
* Accounted's defensible edge: a single, structured pre-flight endpoint that
|
||||
* surfaces the same compliance checks the MCP / dashboard run, in a form
|
||||
* an agent can act on programmatically.
|
||||
*
|
||||
@@ -204,7 +204,7 @@ registerEndpoint({
|
||||
path: '/api/v1/companies/:companyId/compliance/check',
|
||||
summary: 'Run a structured compliance pre-flight check.',
|
||||
description:
|
||||
'Generalised pre-flight that consolidates the gnubok pre-close validators under one envelope. Supported check types: year_end_readiness (BFNAR 2017:3 + ÅRL 2:1 blockers), voucher_gaps (BFNAR 2013:2 kap 8 § series continuity). vat_close is planned for a follow-up PR (the underlying function currently lives in the MCP extension and core routes cannot import from extensions; it will be extracted into lib/reports/ then exposed here). New types can be added without changing the response shape.',
|
||||
'Generalised pre-flight that consolidates the Accounted pre-close validators under one envelope. Supported check types: year_end_readiness (BFNAR 2017:3 + ÅRL 2:1 blockers), voucher_gaps (BFNAR 2013:2 kap 8 § series continuity). vat_close is planned for a follow-up PR (the underlying function currently lives in the MCP extension and core routes cannot import from extensions; it will be extracted into lib/reports/ then exposed here). New types can be added without changing the response shape.',
|
||||
useWhen:
|
||||
'Before committing to an irreversible action (VAT close, year-end close), or as a periodic audit sweep to surface blockers before they become urgent.',
|
||||
doNotUseFor:
|
||||
|
||||
@@ -62,7 +62,7 @@ registerEndpoint({
|
||||
description:
|
||||
'Accepts a SIE4 file (CP437 / Windows-1252 / UTF-8 auto-detected, up to 50 MB) as the request body, parses it, checks for duplicate imports by file-hash, and replays every #VER + #TRANS into the company\'s bookkeeping. Returns an `operation_id` immediately — poll `GET /api/v1/operations/{id}` for status + final result. The byte-equivalent dashboard route at /api/import/sie/execute backs the same lib helper, so a SIE imported via v1 matches what the dashboard would produce.',
|
||||
useWhen:
|
||||
'Migrating bookkeeping data from another system (Fortnox, Bokio, Visma) into gnubok, restoring from a backup .se file, or recreating a period from an archive.',
|
||||
'Migrating bookkeeping data from another system (Fortnox, Bokio, Visma) into Accounted, restoring from a backup .se file, or recreating a period from an archive.',
|
||||
doNotUseFor:
|
||||
'Bank transaction CSV/XML imports (use POST /imports/bank). Single-voucher creation (use POST /journal-entries). Importing into a period that already has posted entries — SIE imports run on a fresh period.',
|
||||
pitfalls: [
|
||||
|
||||
@@ -69,11 +69,11 @@ registerEndpoint({
|
||||
path: '/api/v1/companies/:companyId/invoices/:id/mark-sent',
|
||||
summary: 'Transition a draft invoice to sent (without emailing).',
|
||||
description:
|
||||
'Marks a draft invoice as sent — for invoices delivered outside gnubok (Peppol, postal, manual email). Allocates the F-series invoice_number atomically (ML 17 kap 24§ p.2). On accounting_method=accrual, also posts the invoice journal entry (Debit AR 1510 / Credit revenue + output VAT). Emits invoice.sent. Idempotent and dry-runnable. The companion :send action (PR-B-2b-3) adds PDF rendering and email delivery on top of this same flow.',
|
||||
'Marks a draft invoice as sent — for invoices delivered outside Accounted (Peppol, postal, manual email). Allocates the F-series invoice_number atomically (ML 17 kap 24§ p.2). On accounting_method=accrual, also posts the invoice journal entry (Debit AR 1510 / Credit revenue + output VAT). Emits invoice.sent. Idempotent and dry-runnable. The companion :send action (PR-B-2b-3) adds PDF rendering and email delivery on top of this same flow.',
|
||||
useWhen:
|
||||
'You delivered the invoice through a channel other than gnubok\'s email (Peppol, postal, your own SMTP) and need to record it as sent so the F-series number is allocated and the journal entry is posted.',
|
||||
'You delivered the invoice through a channel other than Accounted\'s email (Peppol, postal, your own SMTP) and need to record it as sent so the F-series number is allocated and the journal entry is posted.',
|
||||
doNotUseFor:
|
||||
'Sending the invoice via gnubok email — use :send (PR-B-2b-3) for that. Marking an already-sent invoice as paid — use :mark-paid (PR-B-2b-2).',
|
||||
'Sending the invoice via Accounted email — use :send (PR-B-2b-3) for that. Marking an already-sent invoice as paid — use :mark-paid (PR-B-2b-2).',
|
||||
pitfalls: [
|
||||
'Only invoices in `status=draft` can be marked sent. Other states return 409 INVOICE_UPDATE_NOT_DRAFT (re-used; the action is structurally an update).',
|
||||
'Allocation is atomic. If a concurrent transition beats the agent\'s request to the same draft, the runner-up gets 409 INVOICE_UPDATE_NOT_DRAFT and no number is consumed.',
|
||||
|
||||
@@ -46,13 +46,13 @@ registerEndpoint({
|
||||
description:
|
||||
'Returns the invoice as application/pdf. The filename in Content-Disposition reflects the document type: faktura-<number>.pdf for sent invoices, kreditfaktura-<number>.pdf for credit notes, utkast-<id-slice>.pdf for drafts. This endpoint is byte-equivalent to the dashboard download.',
|
||||
useWhen:
|
||||
'You need to fetch an invoice PDF for archival, forwarding to a customer outside the gnubok send flow, or attaching to an external workflow.',
|
||||
'You need to fetch an invoice PDF for archival, forwarding to a customer outside the Accounted send flow, or attaching to an external workflow.',
|
||||
doNotUseFor:
|
||||
'Sending the invoice to the customer — use POST /invoices/{id}/send, which renders the PDF, emails it, and archives it as a verifikationsunderlag in one atomic step.',
|
||||
pitfalls: [
|
||||
'Drafts (no invoice_number yet) render with an "utkast" filename. The PDF carries no F-series number — do not treat it as a finalized invoice.',
|
||||
'PDF rendering can take several hundred milliseconds for invoices with many line items. Cache on the client if requesting repeatedly.',
|
||||
'Credit notes embed the original invoice\'s löpnummer per ML 17 kap 22–23§ — if the original was hard-deleted (not possible via gnubok but theoretically via a manual DB edit), the reference is omitted.',
|
||||
'Credit notes embed the original invoice\'s löpnummer per ML 17 kap 22–23§ — if the original was hard-deleted (not possible via Accounted but theoretically via a manual DB edit), the reference is omitted.',
|
||||
],
|
||||
example: {
|
||||
response: {
|
||||
|
||||
@@ -82,7 +82,7 @@ registerEndpoint({
|
||||
description:
|
||||
'The full send pipeline: preflight PDF render → allocate F-series number atomically → final PDF render → email via Resend (PDF attachment, copy to company) → flip status to sent → post journal entry (accrual + real invoice) → archive PDF as underlag → emit invoice.sent. Email failure is a hard 502 before state changes; post-email failures surface as warnings but the invoice IS marked sent.',
|
||||
useWhen:
|
||||
'You want gnubok to deliver the invoice to the customer via email. For invoices delivered through another channel (Peppol, postal, own SMTP) use :mark-sent instead.',
|
||||
'You want Accounted to deliver the invoice to the customer via email. For invoices delivered through another channel (Peppol, postal, own SMTP) use :mark-sent instead.',
|
||||
doNotUseFor:
|
||||
'Re-sending an already-sent invoice (returns 409 INVOICE_UPDATE_NOT_DRAFT). Sending a delivery note (no F-series lifecycle). Sending a credit note (use the :credit endpoint to issue the kreditfaktura; subsequent re-send of the credit note via :mark-sent is the supported path).',
|
||||
pitfalls: [
|
||||
|
||||
@@ -354,7 +354,7 @@ describe('GET /reports/sie-export', () => {
|
||||
},
|
||||
}),
|
||||
)
|
||||
mocks.generateSIEExport.mockResolvedValue('#FLAGGA 0\n#PROGRAM gnubok\n')
|
||||
mocks.generateSIEExport.mockResolvedValue('#FLAGGA 0\n#PROGRAM Accounted\n')
|
||||
|
||||
const res = await sieExport(
|
||||
makeReq(
|
||||
|
||||
@@ -70,7 +70,7 @@ registerEndpoint({
|
||||
gap_start: 142,
|
||||
gap_end: 145,
|
||||
explanation:
|
||||
'Migration from previous bookkeeping system on 2026-05-12 — series A148-onwards corresponds to the new gnubok numbering; numbers A142-A145 were assigned in the legacy system to manual paper vouchers archived offline (BFL 7 kap retention applies). Paper vouchers are stored in the company archive under reference 2026-PAPER-Q2.',
|
||||
'Migration from previous bookkeeping system on 2026-05-12 — series A148-onwards corresponds to the new Accounted numbering; numbers A142-A145 were assigned in the legacy system to manual paper vouchers archived offline (BFL 7 kap retention applies). Paper vouchers are stored in the company archive under reference 2026-PAPER-Q2.',
|
||||
},
|
||||
response: {
|
||||
data: { id: '0e9c…', voucher_series: 'A', gap_start: 142, gap_end: 145 },
|
||||
|
||||
@@ -84,9 +84,9 @@ export const POST = withApiV1<{ params: Promise<{ companyId: string; id: string
|
||||
// Data minimisation (Art.25(2)): the test payload deliberately omits
|
||||
// any internal identifier that has no value to the receiver. The
|
||||
// X-Gnubok-Delivery header on the outbound request already correlates
|
||||
// to the audit trail on the gnubok side.
|
||||
// to the audit trail on the Accounted side.
|
||||
const payload = {
|
||||
hello: 'from gnubok',
|
||||
hello: 'from Accounted',
|
||||
tested_at: new Date().toISOString(),
|
||||
}
|
||||
|
||||
|
||||
@@ -354,7 +354,7 @@ export const POST = withApiV1<{ params: Promise<{ companyId: string }> }>(
|
||||
}
|
||||
|
||||
// Secret returned exactly once. Caller must persist it on the receiver
|
||||
// side — gnubok will not surface it on any subsequent endpoint.
|
||||
// side — Accounted will not surface it on any subsequent endpoint.
|
||||
// Cache-Control: no-store mirrors the rotate-secret response (A.8.12 /
|
||||
// Art.25) so no intermediary (CDN / proxy / gateway log / browser
|
||||
// cache) persists the secret beyond the direct response chain.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
/**
|
||||
* /llms.txt — agent-discoverable index of the gnubok API.
|
||||
* /llms.txt — agent-discoverable index of the Accounted API.
|
||||
*
|
||||
* Convention adopted by Stripe, Anthropic, and other agent-facing platforms:
|
||||
* a plain-text Markdown file at the doc root that points LLM crawlers and
|
||||
@@ -15,17 +15,17 @@ import { getCanonicalBaseUrl } from '@/lib/api/v1/base-url'
|
||||
export async function GET(_request: Request) {
|
||||
const base = getCanonicalBaseUrl()
|
||||
|
||||
const body = `# gnubok API
|
||||
const body = `# Accounted API
|
||||
|
||||
> Swedish double-entry bookkeeping as a public REST API. API version ${API_V1_VERSION}.
|
||||
|
||||
This API lets agents and integrations do anything the gnubok dashboard can do —
|
||||
This API lets agents and integrations do anything the Accounted dashboard can do —
|
||||
read transactions, create invoices, mark them paid, run VAT reports, file year-end
|
||||
declarations, ingest SIE files, and subscribe to webhooks for state changes.
|
||||
|
||||
## Quickstart
|
||||
|
||||
1. Create an API key in the gnubok dashboard at /settings/api.
|
||||
1. Create an API key in the Accounted dashboard at /settings/api.
|
||||
2. Authenticate with \`Authorization: Bearer gnubok_sk_<live|test>_<random>\`.
|
||||
3. List companies the key can access: \`GET ${base}/api/v1/companies\`.
|
||||
4. Use the returned \`id\` as \`{companyId}\` in subsequent paths.
|
||||
|
||||
@@ -22,7 +22,7 @@ import { formatCurrency } from '@/lib/utils'
|
||||
// Reject is always one-click.
|
||||
//
|
||||
// The card posts to the existing /api/pending-operations/<id>/{commit,reject}
|
||||
// endpoints — same surface the gnubok "Förslag" page uses, so there is
|
||||
// endpoints — same surface the Accounted "Förslag" page uses, so there is
|
||||
// exactly one approval source of record.
|
||||
//
|
||||
// Structured preview: when the staged envelope carries a preview object, we
|
||||
@@ -228,7 +228,7 @@ export default function ApprovalCard({
|
||||
}
|
||||
}
|
||||
// The server's `message` field (e.g. "Operation staged for review …
|
||||
// Open the gnubok web app to approve or reject it.") was written for
|
||||
// Open the Accounted web app to approve or reject it.") was written for
|
||||
// MCP clients without an inline approval surface. Inside the in-app
|
||||
// chat it's redundant noise — the agent already narrated the why
|
||||
// above the card. We keep it accessible via aria-description for
|
||||
|
||||
@@ -81,13 +81,13 @@ export default function ChatSidebar({ initialConversations }: Props) {
|
||||
// conversation pane runs nearly edge-to-edge.
|
||||
const [collapsed, setCollapsed] = useState(true)
|
||||
useEffect(() => {
|
||||
const stored = localStorage.getItem('gnubok:chat-sidebar-collapsed')
|
||||
const stored = localStorage.getItem('Accounted:chat-sidebar-collapsed')
|
||||
if (stored === 'false') setCollapsed(false)
|
||||
}, [])
|
||||
const toggleCollapsed = () => {
|
||||
setCollapsed(c => {
|
||||
const next = !c
|
||||
try { localStorage.setItem('gnubok:chat-sidebar-collapsed', next ? 'true' : 'false') } catch {}
|
||||
try { localStorage.setItem('Accounted:chat-sidebar-collapsed', next ? 'true' : 'false') } catch {}
|
||||
return next
|
||||
})
|
||||
}
|
||||
|
||||
@@ -12,7 +12,7 @@ import {
|
||||
import { useCompany } from '@/contexts/CompanyContext'
|
||||
import type { CashAccount } from '@/types'
|
||||
|
||||
const STORAGE_KEY_PREFIX = 'gnubok:cash-account:'
|
||||
const STORAGE_KEY_PREFIX = 'Accounted:cash-account:'
|
||||
|
||||
interface Props {
|
||||
/**
|
||||
|
||||
@@ -15,7 +15,7 @@ import { Lock } from 'lucide-react'
|
||||
import { useCompany } from '@/contexts/CompanyContext'
|
||||
import type { FiscalPeriod } from '@/types'
|
||||
|
||||
const STORAGE_KEY_PREFIX = 'gnubok:fiscal-year:'
|
||||
const STORAGE_KEY_PREFIX = 'Accounted:fiscal-year:'
|
||||
const ALL_YEARS_VALUE = '__all__'
|
||||
|
||||
interface Props {
|
||||
|
||||
@@ -25,7 +25,7 @@ interface Props {
|
||||
className?: string
|
||||
}
|
||||
|
||||
const STORAGE_KEY_PREFIX = 'gnubok:report-range-preset:'
|
||||
const STORAGE_KEY_PREFIX = 'Accounted:report-range-preset:'
|
||||
|
||||
const PRESETS: Preset[] = ['full_year', 'ytd', 'this_month', 'last_month', 'this_quarter', 'custom']
|
||||
|
||||
|
||||
@@ -140,7 +140,7 @@ interface SIEFileStatus {
|
||||
alreadyImported: boolean
|
||||
importedAt: string | null
|
||||
// New (period-based) detection. When present, this fiscal year already has a
|
||||
// completed import in gnubok and a re-sync will replace it (cancelling the
|
||||
// completed import in Accounted and a re-sync will replace it (cancelling the
|
||||
// imported journal entries; user-created entries are untouched).
|
||||
previousImport: {
|
||||
importedAt: string | null
|
||||
|
||||
@@ -152,7 +152,13 @@ export default function LinkVoucherPicker({
|
||||
})
|
||||
return
|
||||
}
|
||||
toast({ title: t('link_success_title'), variant: 'success' })
|
||||
const body = await response.json().catch(() => null)
|
||||
const reconciledTxId = body?.data?.reconciled_transaction_id ?? null
|
||||
toast({
|
||||
title: t('link_success_title'),
|
||||
description: reconciledTxId ? t('link_success_tx_reconciled') : undefined,
|
||||
variant: 'success',
|
||||
})
|
||||
onLinked()
|
||||
} catch (err) {
|
||||
toast({
|
||||
|
||||
@@ -24,7 +24,7 @@ export interface MemberCompany {
|
||||
|
||||
export interface TicPickerCompany {
|
||||
role: EnrichmentCompanyRole
|
||||
/** 'new' = not in gnubok, can set up. 'exists' = in gnubok but user is not a member. */
|
||||
/** 'new' = not in Accounted, can set up. 'exists' = in Accounted but user is not a member. */
|
||||
status: 'new' | 'exists'
|
||||
}
|
||||
|
||||
|
||||
@@ -197,7 +197,7 @@ export default function NewUserChecklist({
|
||||
</div>
|
||||
|
||||
{/* Step 3: Connect Skatteverket — only when the extension is enabled.
|
||||
Optional: connecting here lets gnubok submit moms + AGI and read
|
||||
Optional: connecting here lets Accounted submit moms + AGI and read
|
||||
skattekonto saldo, but the user can skip and do it later from
|
||||
/settings/skatteverket. The OAuth flow returns to the dashboard
|
||||
via return_to=/, which clears the gate via the same path the
|
||||
|
||||
@@ -96,7 +96,7 @@ export default function Step2CompanyDetails({
|
||||
|
||||
const orgNumber = watch('org_number')
|
||||
|
||||
// Debounced duplicate check against gnubok's own companies table. Runs in
|
||||
// Debounced duplicate check against Accounted's own companies table. Runs in
|
||||
// parallel with the TIC lookup — they don't conflict. On match, the submit
|
||||
// button is disabled; the server action would also reject ('org_number_exists')
|
||||
// but blocking client-side avoids a wasted roundtrip.
|
||||
|
||||
@@ -153,6 +153,8 @@ export function BankReconciliationView() {
|
||||
const [applyLoading, setApplyLoading] = useState(false)
|
||||
const [linkLoading, setLinkLoading] = useState<string | null>(null)
|
||||
const [unlinkLoading, setUnlinkLoading] = useState<string | null>(null)
|
||||
// Per-verifikat loading for the "Märk som ingående balans" re-tag action.
|
||||
const [markLoading, setMarkLoading] = useState<string | null>(null)
|
||||
const [actionLoading, setActionLoading] = useState<string | null>(null)
|
||||
|
||||
// Opt-in: also surface vouchers already matched to a bank transaction as
|
||||
@@ -408,6 +410,34 @@ export function BankReconciliationView() {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Re-tag a manual/import voucher that is really an ingående balans as
|
||||
* source_type='opening_balance'. Such a voucher (common after a migration
|
||||
* where the IB was booked as an ordinary verifikat) otherwise stays in the
|
||||
* period movement and shows up as a phantom difference equal to the IB. After
|
||||
* re-tagging it drops out of the diff and is surfaced as "IB — räknas inte".
|
||||
*/
|
||||
const handleMarkOpeningBalance = async (journalEntryId: string) => {
|
||||
setMarkLoading(journalEntryId)
|
||||
try {
|
||||
const res = await fetch('/api/reconciliation/bank/mark-opening-balance', {
|
||||
method: 'POST',
|
||||
headers: { 'Content-Type': 'application/json' },
|
||||
body: JSON.stringify({ journal_entry_id: journalEntryId }),
|
||||
})
|
||||
const result = await res.json()
|
||||
if (result.error) {
|
||||
setError(result.error)
|
||||
} else {
|
||||
await fetchAll()
|
||||
}
|
||||
} catch {
|
||||
setError('Kunde inte markera verifikationen som ingående balans')
|
||||
} finally {
|
||||
setMarkLoading(null)
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Inline one-click booking for an unmatched transaction with no upstream
|
||||
* voucher to match against (ränteintäkter, bankavgifter, valutakurs-
|
||||
@@ -883,6 +913,9 @@ export function BankReconciliationView() {
|
||||
</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<p className="mb-3 text-xs text-muted-foreground">
|
||||
Är en manuellt eller importerat bokförd verifikation egentligen en ingående balans? Markera den som IB — då räknas den inte med i avstämningen utan visas separat som ingående balans.
|
||||
</p>
|
||||
<table className="w-full text-sm">
|
||||
<thead className="[&_th]:font-medium [&_th]:text-[11px] [&_th]:uppercase [&_th]:tracking-wider [&_th]:text-muted-foreground">
|
||||
<tr className="border-b text-left">
|
||||
@@ -891,11 +924,13 @@ export function BankReconciliationView() {
|
||||
<th className="py-2">Beskrivning</th>
|
||||
<th className="py-2 w-28 text-right">Belopp</th>
|
||||
<th className="py-2 w-24">Typ</th>
|
||||
<th className="py-2 w-36"></th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{unmatchedGlLines.map((line) => {
|
||||
const amount = line.debit_amount > 0 ? line.debit_amount : -line.credit_amount
|
||||
const isRetaggable = line.source_type === 'manual' || line.source_type === 'import'
|
||||
return (
|
||||
<tr key={line.line_id} className="border-b last:border-0">
|
||||
<td className="py-2 font-mono text-xs">
|
||||
@@ -909,6 +944,20 @@ export function BankReconciliationView() {
|
||||
{formatCurrency(amount)}
|
||||
</td>
|
||||
<td className="py-2 text-xs text-muted-foreground">{line.source_type}</td>
|
||||
<td className="py-2 text-right">
|
||||
{isRetaggable && (
|
||||
<Button
|
||||
size="sm"
|
||||
variant="ghost"
|
||||
className="h-8 text-xs"
|
||||
disabled={markLoading === line.journal_entry_id}
|
||||
onClick={() => handleMarkOpeningBalance(line.journal_entry_id)}
|
||||
title="Markera verifikationen som ingående balans — den utesluts då från avstämningen"
|
||||
>
|
||||
{markLoading === line.journal_entry_id ? 'Markerar…' : 'Märk som IB'}
|
||||
</Button>
|
||||
)}
|
||||
</td>
|
||||
</tr>
|
||||
)
|
||||
})}
|
||||
|
||||
@@ -594,7 +594,7 @@ function SkatteverketPanelInner({ periodType, year, period, hasData, rutor }: Sk
|
||||
)}
|
||||
|
||||
{/* Local pre-flight check results — surfaced separately from SKV's
|
||||
kontroller so the user knows these are gnubok's own sanity checks,
|
||||
kontroller so the user knows these are Accounted's own sanity checks,
|
||||
not Skatteverket's. ERRORs block the submit/validate buttons. */}
|
||||
{localChecks.length > 0 && (
|
||||
<div className="space-y-1.5">
|
||||
|
||||
@@ -4,11 +4,11 @@ import { useCallback, useEffect, useState } from 'react'
|
||||
|
||||
/**
|
||||
* Tracks the last few report slugs the user opened, per company, in
|
||||
* localStorage. Mirrors the `gnubok:<key>:<companyId>` convention used by
|
||||
* localStorage. Mirrors the `Accounted:<key>:<companyId>` convention used by
|
||||
* FiscalYearSelector (STORAGE_KEY_PREFIX). Powers the "Senast öppnade" shelf
|
||||
* so returning users skip the library hop.
|
||||
*/
|
||||
const STORAGE_KEY_PREFIX = 'gnubok:report-recents:'
|
||||
const STORAGE_KEY_PREFIX = 'Accounted:report-recents:'
|
||||
const MAX_RECENTS = 4
|
||||
|
||||
export function useRecentReports(companyId: string | null | undefined) {
|
||||
|
||||
@@ -26,7 +26,7 @@ interface EstimateResponse {
|
||||
within_limit: boolean
|
||||
}
|
||||
|
||||
const LAST_DOWNLOAD_STORAGE_KEY = 'gnubok:last-backup-download'
|
||||
const LAST_DOWNLOAD_STORAGE_KEY = 'Accounted:last-backup-download'
|
||||
|
||||
export function BackupDownloadForm() {
|
||||
const t = useTranslations('settings_backup_download')
|
||||
|
||||
@@ -97,7 +97,7 @@ export default function TransactionInboxCard({
|
||||
// upload POST succeeds, without waiting for the parent to refetch. The
|
||||
// next parent refresh will sync; in the meantime the user sees the
|
||||
// correct visual state immediately. Same hook handles agent-chat uploads
|
||||
// via the gnubok:transaction-document-linked window event (AgentChat
|
||||
// via the Accounted:transaction-document-linked window event (AgentChat
|
||||
// dispatches it after /api/agent/upload returns).
|
||||
const [optimisticDocumentId, setOptimisticDocumentId] = useState<string | null>(null)
|
||||
useEffect(() => {
|
||||
@@ -106,8 +106,8 @@ export default function TransactionInboxCard({
|
||||
if (!detail || detail.transaction_id !== transaction.id || !detail.document_id) return
|
||||
setOptimisticDocumentId(detail.document_id)
|
||||
}
|
||||
window.addEventListener('gnubok:transaction-document-linked', onLinked)
|
||||
return () => window.removeEventListener('gnubok:transaction-document-linked', onLinked)
|
||||
window.addEventListener('Accounted:transaction-document-linked', onLinked)
|
||||
return () => window.removeEventListener('Accounted:transaction-document-linked', onLinked)
|
||||
}, [transaction.id])
|
||||
const attachedDocumentId =
|
||||
optimisticDocumentId ?? (transaction as { document_id?: string | null }).document_id ?? null
|
||||
|
||||
@@ -17,7 +17,7 @@ interface RetentionNoticeProps {
|
||||
* account danger zone and the company danger zone.
|
||||
*
|
||||
* Swedish Bokföringslagen (BFL) 7 kap. 2§ requires räkenskapsinformation
|
||||
* to be retained for 7 years. gnubok is the system of record, so deleting
|
||||
* to be retained for 7 years. Accounted is the system of record, so deleting
|
||||
* a company or an account does not remove the underlying data — it only
|
||||
* hides it from the UI and anonymizes PII where applicable.
|
||||
*/
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
|
||||
## The App
|
||||
|
||||
gnubok is a Swedish accounting platform for sole traders (enskild firma) and limited companies (aktiebolag). It handles the legally required bookkeeping and financial management that every Swedish business needs.
|
||||
Accounted is a Swedish accounting platform for sole traders (enskild firma) and limited companies (aktiebolag). It handles the legally required bookkeeping and financial management that every Swedish business needs.
|
||||
|
||||
## Core Functionality
|
||||
|
||||
@@ -654,7 +654,7 @@ Core runs with zero extensions. This gives you the standard accounting system: b
|
||||
|
||||
```bash
|
||||
# 1. Clone and install
|
||||
git clone <repo-url> && cd gnubok
|
||||
git clone <repo-url> && cd Accounted
|
||||
npm install
|
||||
|
||||
# 2. Set environment variables (minimum 4)
|
||||
|
||||
@@ -3,7 +3,7 @@ import { registerBrandingService } from '@/lib/branding/service'
|
||||
|
||||
// Register the whitelabel branding values immediately when this extension is loaded.
|
||||
// Edit the values below to match your brand. Any field omitted falls back to the
|
||||
// gnubok default (and to whatever you've set via env vars). See WHITELABEL.md.
|
||||
// Accounted default (and to whatever you've set via env vars). See WHITELABEL.md.
|
||||
registerBrandingService({
|
||||
// appName: 'YourBrand',
|
||||
// appDescription: 'Bokföring & redovisning',
|
||||
|
||||
@@ -63,7 +63,7 @@ function translateOAuthError(error: string, description: string | null): string
|
||||
* Provider Migration extension
|
||||
*
|
||||
* Migrates bookkeeping data from external Swedish accounting systems
|
||||
* (Fortnox, Visma, Bokio, Björn Lundén, Briox) into gnubok by talking
|
||||
* (Fortnox, Visma, Bokio, Björn Lundén, Briox) into Accounted by talking
|
||||
* directly to each provider's API.
|
||||
*
|
||||
* Bookkeeping data (accounts, balances, vouchers) is imported via SIE
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
/**
|
||||
* Maps Arcim Sync canonical DTOs to gnubok internal types.
|
||||
* Maps Arcim Sync canonical DTOs to Accounted internal types.
|
||||
*
|
||||
* These mappers transform the normalized data from any Swedish accounting
|
||||
* provider into the exact shapes gnubok expects for database insertion.
|
||||
* provider into the exact shapes Accounted expects for database insertion.
|
||||
*/
|
||||
|
||||
import type { CustomerType, SupplierType, VatTreatment } from '@/types'
|
||||
@@ -275,11 +275,11 @@ export function mapSalesInvoice(
|
||||
const primaryTaxPercent = dto.lines.find(l => l.taxPercent != null)?.taxPercent
|
||||
const vatTreatment = inferVatTreatment(primaryTaxPercent, dto.currencyCode)
|
||||
|
||||
// Map Arcim status to gnubok status
|
||||
// Map Arcim status to Accounted status
|
||||
const statusMap: Record<string, string> = {
|
||||
draft: 'draft',
|
||||
sent: 'sent',
|
||||
booked: 'sent', // gnubok has no 'booked' status — treat as sent
|
||||
booked: 'sent', // Accounted has no 'booked' status — treat as sent
|
||||
paid: 'paid',
|
||||
overdue: 'overdue',
|
||||
cancelled: 'cancelled',
|
||||
|
||||
@@ -133,7 +133,7 @@ export async function executeMigration(options: MigrationOptions): Promise<Migra
|
||||
}
|
||||
|
||||
// ── Step 2: Customers (bulk) ──────────────────────────────────
|
||||
// customerIdMap: provider customer id → gnubok customer id.
|
||||
// customerIdMap: provider customer id → Accounted customer id.
|
||||
// orgNumberToCustomerId / nameToCustomerId speed up invoice lookup
|
||||
// without extra queries later.
|
||||
const customerIdMap = new Map<string, string>()
|
||||
|
||||
@@ -236,7 +236,7 @@ export default function CloudBackupCard() {
|
||||
<>
|
||||
<p className="text-sm text-muted-foreground leading-relaxed">
|
||||
Koppla ditt Google-konto för att ladda upp säkerhetsbackupen till din egen Drive.
|
||||
gnubok får bara tillgång till filer som appen själv skapar (scope{' '}
|
||||
Accounted får bara tillgång till filer som appen själv skapar (scope{' '}
|
||||
<span className="font-mono text-xs">drive.file</span>).
|
||||
</p>
|
||||
<div className="mt-4">
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
"dataPattern": "manual",
|
||||
"hasOwnData": true,
|
||||
"description": "Synka säkerhetsbackup till din egen molnlagring",
|
||||
"longDescription": "Koppla ditt Google Drive-konto och ladda upp en fullständig säkerhetsbackup med ett klick. Gnubok skapar en ZIP med SIE-filer, kvitton och behandlingshistorik och laddar upp till en egen mapp i din Drive. Perfekt för att uppfylla egna krav på redundans.",
|
||||
"longDescription": "Koppla ditt Google Drive-konto och ladda upp en fullständig säkerhetsbackup med ett klick. Accounted skapar en ZIP med SIE-filer, kvitton och behandlingshistorik och laddar upp till en egen mapp i din Drive. Perfekt för att uppfylla egna krav på redundans.",
|
||||
"subscriptionNotice": "Kräver ett Google-konto. Uppladdningar sker direkt till din Drive — ingen data lagras hos tredje part utöver Google."
|
||||
}
|
||||
}
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user