Files
accounted/.github/workflows/core-build.yml
T
Jakob Wennberg df34cae9bf feat(packs): konteringspaket as validated data files (phase 2a) (#1386)
* feat(packs): konteringspaket as validated data files, ported losslessly

The 26 system booking templates lived inside migration 20260413160000. Under
the never-modify-a-shipped-migration rule that froze them: correcting a wrong
BAS account or a Swedish typo needed a whole new migration, and nothing checked
that a seeded account existed in the chart or that a template balanced. #1321
was exactly that failure with seeded chart names.

They are now one YAML file per pattern under packs/, with a Zod contract and a
CI gate. A correction becomes a one-line edit plus a green run.

The port is proven lossless, not asserted. The test fixture was read out of a
Postgres with all 548 migrations applied, so it is the exact JSONB production
holds; lib/packs/__tests__/port-is-lossless.test.ts asserts the YAML reproduces
it by value. Phase 2b can swap the seeded rows for the loader as a no-op.

The gate checks what makes a pack CORRECT, not just well-formed, because #1321
was structurally valid and still wrong: every account must exist in BAS 2026,
and every pack must balance at five probe amounts through the real
applyTemplate() rather than a reimplementation. Account numbers validate through
lib/invariants, so a pack cannot disagree with the API or the SIE importer about
what an account number is.

Doing that immediately found four pre-existing breakages in the shipped
templates:

  loneutbetalning                    debits total 1.42x the amount against a
                                     1.0 credit: it can never post
  periodiseringsfond-avsattning-ab   account 2113 is not in BAS 2026 and is not
  periodiseringsfond-aterforing-ab   seeded into any company chart
  preliminar-f-skatt-ef              account 2012, same problem

These are quarantined in KNOWN_BROKEN, not fixed and not hidden: a quarantined
pack's findings are warnings, any NEW finding fails the build, and the validator
fails if a quarantined pack turns out to be clean, so the list may only shrink.
Each is a Swedish accounting content change to a user-facing template, which
deserves its own review rather than riding along inside a file-format change.

Five shipped descriptions contain em dashes, preserved verbatim and pinned by a
test: a lossless port must not silently rewrite user-visible strings.

js-yaml is promoted from a transitive dependency to a declared one (MIT, already
in node_modules), so the catalogue does not depend on it by accident.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(deps): regenerate package-lock.json with npm 10 to match CI

`npm ci` failed on every job with "Missing: @swc/helpers@0.5.23 from lock
file". The lockfile was written by local npm 11.6.0; CI runs npm 10.8.2 on
node 20, and npm 11 emits a tree npm 10 reads as out of sync.

Regenerated with `npx npm@10 install --package-lock-only`, which cuts the diff
from a sprawling rewrite down to the three entries this branch actually adds
(js-yaml, @types/js-yaml, and the @swc/helpers entry npm 11 had dropped).
Verified with `npx npm@10 ci --dry-run`.

This is the documented gotcha for this repo: regenerate lockfiles with
npx npm@10, never with a local npm 11.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 18:05:54 +02:00

151 lines
6.6 KiB
YAML

name: Core Build (no extensions)
# Split out of a single serial job that took 7m43s wall-clock: npm ci 24s, lint
# ratchet 1m29s, build 2m00s, unit tests 3m31s, ratchets ~10s. None of those
# stages needed the previous one's output, so they were serial only by
# accident. Running them as independent jobs (and sharding the 897-file unit
# suite four ways) puts the critical path on `build` at roughly 2m30s.
#
# The prologue each job needs is in .github/actions/setup-core.
on: [pull_request]
# Six concurrent jobs per push makes stale runs far more expensive than they
# were when this was one job, and a superseded push has nothing worth finishing.
concurrency:
group: core-build-${{ github.ref }}
cancel-in-progress: true
permissions:
contents: read
jobs:
checks:
name: Checks
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
with:
# Nothing here pushes, so leaving the token in .git/config only widens
# what a compromised dependency in the build could reach.
persist-credentials: false
- uses: ./.github/actions/setup-core
- name: Verify skill bodies are in sync with the seed migration
# Fails if a .claude/skills/**/SKILL.md changed without regenerating the
# seed migration (npm run skills:generate). Keeps prod skill content from
# silently drifting out of sync. No DB needed: reads files + manifest.
run: npm run skills:check
- name: Verify taxonomy registry is in sync with the element lists
# Fails if dev_docs/bokslut/taxonomi/** changed without regenerating
# lib/bokslut/ixbrl/taxonomy/generated/ (npm run taxonomy:generate).
# The iXBRL generator emits facts strictly from the generated registry,
# so drift here means filings tagged against a stale concept set.
run: npm run taxonomy:check
- name: Lint ratchet (no new ESLint errors)
# `npm run lint` was never wired into CI, so ~60 legacy errors
# accumulated. This ratchet (sibling of check:guards) fails only when
# a PR ADDS an error beyond scripts/checks/eslint-baseline.json; the
# baseline ratchets down as legacy errors get fixed.
run: npm run check:lint
- name: Antipattern ratchet (no new MFA-bypassing routes / naive öre-rounding)
# Fails only if a PR ADDS a route that hand-rolls supabase.auth.getUser()
# instead of the MFA-enforcing guard, or a new Math.round(x*100)/100.
# Baseline lives in scripts/checks/antipatterns-baseline.json and ratchets
# down as the A1 (route auth) and D1 (rounding) migrations land.
run: npm run check:guards
- name: Validate konteringspaket catalogue
# The system booking templates are data files under packs/ rather than
# rows frozen inside a migration. This gate is what makes that safe: it
# checks the schema, that every BAS account actually exists in the 2026
# chart, and that each pack BALANCES when applied through the real
# applyTemplate(). PR #1321 shipped seeded reference data that
# contradicted the engine; that class of bug is structurally valid and
# only a semantic check catches it.
run: npm run validate:packs
- name: Check no core imports from extensions
run: |
VIOLATIONS=$(grep -r "from '@/extensions/" lib/ app/api/ components/ --include="*.ts" --include="*.tsx" \
| grep -v "app/api/extensions/" \
| grep -v "components/extensions/" \
| grep -v "lib/extensions/_generated/" \
| grep -v "lib/extensions/loader.ts" || true)
if [ -n "$VIOLATIONS" ]; then
echo "ERROR: Core code imports from @/extensions/:"
echo "$VIOLATIONS"
exit 1
fi
build:
name: Build (zero extensions)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
with:
# Nothing here pushes, so leaving the token in .git/config only widens
# what a compromised dependency in the build could reach.
persist-credentials: false
- uses: ./.github/actions/setup-core
- run: npm run build
test:
# 897 unit test files (11,341 tests) take 3m31s in one process. Measured
# locally, four shards split them 225/224/224/224 with the slowest at 64s,
# which puts this comfortably under the build job so it stops being the
# critical path. Vitest hard-errors when the shard count exceeds the
# resolved file count, which is nowhere near a concern at this size.
name: Unit tests (${{ matrix.shard }}/4)
runs-on: ubuntu-latest
strategy:
# One shard failing should not hide failures in the other three: a red PR
# is more useful when it lists every broken test, not just the first.
fail-fast: false
matrix:
shard: [1, 2, 3, 4]
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
with:
# Nothing here pushes, so leaving the token in .git/config only widens
# what a compromised dependency in the build could reach.
persist-credentials: false
- uses: ./.github/actions/setup-core
# Via env rather than interpolated straight into the shell body: the value
# is a static matrix integer and harmless, but keeping every `run:` free of
# ${{ }} is the rule that makes the template-injection audit meaningful.
- run: npm test -- --shard="$SHARD/4"
env:
SHARD: ${{ matrix.shard }}
core-build:
# One stable check name covering all six jobs above, so the PR checks list
# (and any future required-status-check rule) has a single thing to read
# rather than a shard-numbered matrix. `needs` alone would not be enough:
# a needed job that is skipped or cancelled does not fail its dependents,
# so the results are asserted explicitly.
name: Core Build
if: always()
needs: [checks, build, test]
runs-on: ubuntu-latest
steps:
- name: Assert every core job succeeded
env:
CHECKS: ${{ needs.checks.result }}
BUILD: ${{ needs.build.result }}
TEST: ${{ needs.test.result }}
run: |
set -euo pipefail
echo "checks=$CHECKS build=$BUILD test=$TEST"
failed=0
for r in "$CHECKS" "$BUILD" "$TEST"; do
[ "$r" = "success" ] || failed=1
done
if [ "$failed" -ne 0 ]; then
echo "::error::One or more core-build jobs did not succeed"
exit 1
fi