df34cae9bf
* 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>
151 lines
6.6 KiB
YAML
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
|