Pin the current (pre-migration) behavior of the Client wizard — the largest SSR
modal: seven linear steps (info → matches → contact → bank-accounts → integrations
→ cash-flow → other-settings) plus the parameterized bank-account sub-editor — so
the upcoming engine migration preserves it.
- e2e/client-wizard.spec.ts: new dialog renders info + the 7-step timeline; edit
opens prefilled with a disabled code; the bank-accounts step shows the seeded
account card and the add-account affordance (the crux sub-step); and an
edit-through-to-save round-trip keeps the client in the grid.
- test_server.clj: give the seeded TEST client a :client/name so the row is
selectable in the admin grid (its base query requires :client/name); also honor
a TEST_SERVER_PORT env var so a from-disk e2e JVM can run on a free port
alongside a REPL-held one (the same parallel-run need the playwright config notes).
Full e2e suite green (69/69) against a fresh from-disk server.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The New Invoice wizard's basic-details step needs a client + vendor in its Solr
typeaheads; tests inject the seeded ids. accounts.vendor was already exposed; add
:clientIds (TEST / TEST2) so the upcoming Phase 8 parity gate can drive the create flow.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Invoice Pay wizard is the first GENUINE multi-data-step wizard: choose-method
(collects bank-account + method) -> payment-details (collects check-number /
handwritten-date / amounts), merged only at submit. This gate characterizes that
flow before migrating it onto the session-backed engine, so the merge can be proven
behavior-preserving.
- Seed: make the TEST client's check bank account visible (+ name "Test Checking")
so the choose-method step renders a usable method card. The pay flow had no e2e
coverage, so the bank account was never visible in tests before.
- Spec drives the real 2-step flow against the unmodified wizard: choose-method
renders the bank account + its methods (print-check/debit/handwrite-check, in the
card tooltip); picking handwrite-check advances to payment-details (check-number +
date + Pay); filling the check number and submitting shows the completion modal.
The handwrite-check path is used because it transacts a pending check payment
directly (no PDF/S3), making the success assertion stable.
Notes for the migration: the method controls live in a <template x-ref="tooltip">
revealed by the card button; the footer Pay submit is x-ref="next"; both the grid
filters and the modal carry a check-number input, so the modal selectors are scoped
to #wizard-form.
Verification: invoice-pay spec 3/3; full suite 58/58 (no regressions from the seed
change).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Behavior-parity safety net before migrating the Transaction Rule modal onto the
session-backed wizard engine. The modal had no e2e coverage; the test server seeded
no rules.
- test_server.clj: seed a transaction rule (under client TEST2, in a SEPARATE
transaction so the first transaction's tempid->entity-id allocation — and thus the
TEST transaction grid order the other specs depend on — is byte-identical); surface
its id via /test-info (ruleId).
- e2e/transaction-rule.spec.ts (4 tests): the new-rule edit step renders (description,
account grid, approval radios, Test control), the edit dialog pre-populates the
seeded rule, advancing to the test step renders the matching-transactions preview,
and saving from the test step creates the rule + closes the modal. Covers both entry
points (new/edit), both steps (edit + test), and save.
Note: deliberately NOT seeding a recent matching transaction — a date-NOW txn perturbs
an unrelated transaction-edit save spec (pre-existing fragility), and the test-table
query/render is reused unchanged by the migration, so characterizing that the preview
renders is sufficient parity.
Full Playwright suite 55/55 (51 prior + 4 new).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Establishes the behavior-parity safety net required before migrating the POS
Sales Summary edit modal off the wizard (the modal had zero test coverage and the
test server seeded no POS data).
- test_server.clj: seed a balanced sales summary ($500 credit = $500 debit) with
two auto items referencing the existing test client + accounts; surface its id
via /test-info (`salesSummaryId`).
- e2e/sales-summary-edit.spec.ts: characterization spec (6 tests) capturing current
behavior — open modal (debit/credit columns, categories, resolved account names,
amounts), balanced state, inline account editor (pencil -> typeahead editor ->
cancel restores / save re-renders the cell), and Save (PUT round-trip closes the
modal + keeps the grid row). Exercises the edit-wizard, edit/save/cancel-item-account,
and edit-wizard-submit routes.
Notable finding: the "New Summary Item" button is currently BROKEN (its Alpine
handler throws "newRowIndex is not defined" and hx-target="closest .new-row"
matches no ancestor, so the new-summary-item route never fires). The spec documents
this as inert rather than asserting it works; the migration will decide fix-vs-preserve.
Full Playwright suite 45/45 (39 prior + 6 new).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Squashed Phase-2 SSR work: migrate the Transaction Edit modal's render path
entirely to Selmer templates (zero Hiccup in the render path), rip out the
multi-step wizard abstraction (EditWizard/LinksStep records, MultiStepFormState,
step-params[...] field names, mm/* middleware) in favor of a plain form with
flat derived state, and promote shared UI components to reusable Selmer partials
under resources/templates/components/. Adds the Selmer interop bridge, the
auto-ap.ssr.components.selmer (sc) wrapper library, and the ssr-form-migration
skill capturing the learnings.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replicate the master CLJS "delete external ledger" feature on the SSR
external ledger page: an admin-only bulk delete that retracts the
selected journal entries, skipping any in a client's locked period and
capping at 1000 per request.
Return the result via modal-response (retargets the persistent
#modal-content shell) and target #modal-content from the button so the
request never relies on the outerHTML swap inherited from the data-grid
card, which previously replaced #modal-holder and broke the next click.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Alphabetize the import.clj :require block (AGENTS.md Import Formatting).
- Remove unused imports (digest, strip) flagged by clj-kondo.
- Make the client-not-found classify-table test independent: it previously
reused the bank-account-not-found input and added zero marginal coverage;
now seeds an orphan bank account so only the client error fires.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Implement the SSR/alpine/htmx manual transaction import, wiring the
already-declared but unhandled ::external-import-page/parse/import routes.
Mirrors the SSR ledger import: paste the exact master-branch Yodlee
positional-column TSV, review parsed rows in an editable grid with per-row
error/warning badges, and import. Every master validation is preserved and
the existing import.transactions engine is reused unchanged
(via import.manual/import-batch), so core components are untouched.
- New ns auto-ap.ssr.transaction.import (page, paste/parse, editable grid,
two-tier validation, import handler) + admin-only transactions Import nav.
- Two-tier validation: fixable problems (bad date/amount, unknown client or
bank-account code, missing fields) are hard errors that block the whole
batch; inherent skip-conditions (non-POSTED, before start-date/locked,
already-imported) are warnings computed from the engine's own
categorize-transaction so the grid preview matches the import result.
- Tests: failing-first Playwright e2e (e2e/transaction-import.spec.ts) plus
unit/integration coverage (ssr/transaction/import_test.clj, 10 tests).
- Deterministic bank-account code in the e2e seed.
Plan: docs/plans/2026-06-01-001-feat-manual-transaction-import-ssr-plan.md
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Add new memo filter to transaction page (searches :transaction/memo)
- Enhance existing description filter to use case-insensitive regex
- Both filters support wildcard matching via .* pattern
- Add e2e tests for filter functionality
- Update test data with memo fields
- vendor-default-account now uses raw vendor default account (not client-specific override)
- Account name is clientized via d-accounts/clientize only for single-client contexts
- Added single-client-id helper that returns client ID only when user has exactly one client
- Added multi-client e2e test verifying no pre-population across multiple clients
- Updated test server to support multi-client mode switching via /test-set-client-mode
- Test server now seeds a second client for multi-client scenarios
- Add vendor-changed HTMX handlers for both bulk code and individual edit
- Pre-populate default account at 100% when vendor is selected and no accounts exist
- Fix render-accounts-section to render from step-params correctly
- Change bulk code vendor-changed from hx-get to hx-post to include form data
- Add routes for vendor-changed endpoints
- Update e2e tests to cover vendor pre-population
- Run lein cljfmt fix across codebase
- Create requirements document based on master cljs implementation
- Add Playwright e2e tests covering happy path, validation, and distribution
- Fix hiccup id syntax in SSR bulk code form (div#id.class order)
- Add missing account location validation to SSR bulk code submit
- Enhance test server with multiple transactions and fixed-location account
Validates existing template correctly parses multi-page invoice with:
- Invoice number 03882095
- Customer identifier NICK THE GREEK
- Account number 600 VISTA WAY
- Total of $946.24
- customer-identifier field: customer name (e.g., 'NICK THE GREEK')
- account-number field: street address (e.g., '600 VISTA WAY')
- Combined they provide full customer identification with address
- Updated test to verify both fields and their concatenation
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Extract city/state/zip in location field
- Customer address now split across 3 fields:
- customer-identifier: customer name
- account-number: street address
- location: city, state zip
- All components verified in test
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Extract customer name in customer-identifier field
- Extract street address in account-number field
- Use non-greedy regex with lookahead to capture clean values
- Update test to verify both name and address extraction
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add new PDF template for Bonanza Produce vendor
- Template uses phone number 530-544-4136 as unique identifier
- Extracts invoice number, date, customer identifier, and total
- Includes passing test for invoice 03881260
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add 2 more route handler tests:
- execute-dialog-route-works: Tests execution dialog for rules
- new-dialog-route-returns-empty-form: Tests new rule form
Total: 17 tests with 26 assertions, all passing.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add comprehensive tests for the SSR admin transaction rules module:
- Rule matching by description pattern
- Rule matching returns empty for no matches
- Validation accepts valid data with 100% account allocation
- Validation rejects invalid account totals
- Rule matching by amount range
- Rule matching by bank account
- Security tests for non-admin access
- Execute validation tests
All 8 tests passing with 9 assertions. Tests focus on the unique
rule matching engine functionality that differentiates transaction
rules from other admin modules.
Includes implementation plan documenting 23 test scenarios
and 6-phase approach for complete coverage.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Added comprehensive test suite for account creation, validation, and grid views
- Documented Datomic entity reference handling patterns in test comments
- Created 5 test improvement todo documents addressing common test anti-patterns
- Todo items cover: removing debug statements, fixing test nesting, strengthening assertions, extracting helpers, and removing doc-only tests
