m/paliad
1
0
Fork 0
Code Issues 151 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Test-data reset: wipe current 12 projects + seed realistic 'Example Projects' that exercise the auto-derived code chain #87

New Issue
Open
opened 2026-05-25 12:16:59 +00:00 by mAi · 0 comments
mAi commented 2026-05-25 12:16:59 +00:00
Collaborator
Copy Link

m's request (2026-05-25 14:15)

No that's good [re: project code semantics] — maybe we can delete our Test data and generate new ones? Some "Example Projects" with good settings?

Current state (live)

paliad.projects has 12 rows, all created by m (matthias.siebels@hoganlovells.com). All are test data — references like C-UPC-0001, L-2026-001, P-EP3456789, no opponent_code set anywhere (which is why auto-derived chain codes don't render). Safe to wipe.

Goal

  1. Wipe the current 12 projects + every cascading row that references them.
  2. Seed ~12-15 realistic patent-litigation projects that exercise the full auto-derived chain (Client.Litigation.Patent.Case → e.g. SIEMENS.HUAW.789.INF.CFI).
  3. Verify the new chain codes render on /projects and project-detail headers.

Suggested example tree (head's editorial — coder may refine)

Client 1 — Siemens AG (reference: SIEMENS)

  • Litigation: Siemens ./. Huawei (opponent_code: HUAW)
    • Patent: EP3456789 — Funkkommunikationssystem mit Mehrfachantenne (patent_number: EP3456789)
      • Case: UPC CFI München — Klage Siemens ./. Huawei (proceeding_type: upc.inf.cfi) → SIEMENS.HUAW.789.INF.CFI
      • Case: UPC CFI München — Widerklage Huawei ./. Siemens (proceeding_type: upc.ccr.cfi, counterclaim_of the above) → SIEMENS.HUAW.789.CCR.CFI
      • Case: UPC CoA — Berufung Huawei (proceeding_type: upc.coa) → SIEMENS.HUAW.789.COA
  • Litigation: Siemens ./. Bosch (opponent_code: BOSCH)
    • Patent: EP1111222 — Sensoreinrichtung für autonomes Fahren (patent_number: EP1111222)
      • Case: LG München I — Klage Siemens ./. Bosch (proceeding_type: de.inf.lg) → SIEMENS.BOSCH.222.INF.LG
      • Case: LG München I — Klageerwiderung Bosch (defendant side perspective; proceeding_type: de.inf.lg) → SIEMENS.BOSCH.222.INF.LG

Client 2 — Bayer AG (reference: BAYER)

  • Litigation: Bayer ./. Novartis (opponent_code: NOVA)
    • Patent: EP2222333 — Wirkstoffverbindung X (patent_number: EP2222333)
      • Case: EPA Einspruch (proceeding_type: ep.opp) → BAYER.NOVA.333.OPP
      • Case: DPMA Nichtigkeit (proceeding_type: de.nul.bpatg) → BAYER.NOVA.333.NUL.BPATG

Client 3 — Beispiel AG (reference: BEISPL)

(intentionally sparse — demonstrates the empty-segment skip)

  • Litigation: Beispiel ./. Wettbewerber (opponent_code: WTB)
    • Patent: DE10987654 (patent_number: DE10987654)
      • Case: DPMA Erteilungsverfahren (proceeding_type may be empty if not modelled) → BEISPL.WTB.654 or similar

Adjust the exact proceeding_type IDs to whatever paliad.proceeding_types has — query the table first; pick ones that produce nice .code tails.

What to do

Phase 1 — Wipe (write a single transaction)

Figure out the full set of paliad.* tables that reference paliad.projects(id) via FK and delete dependents in dependency order. Likely set:

  • paliad.deadlines (anchors, actuals)
  • paliad.appointments
  • paliad.party_assignments (or whatever links parties to projects)
  • paliad.parties if they're project-scoped
  • paliad.notes
  • paliad.events / project_events audit feed
  • paliad.team_memberships
  • paliad.checklist_instances
  • paliad.submission_drafts
  • paliad.custom_views IF they were created tied to a project (likely user-scoped, leave them)
  • paliad.approval_requests
  • Any other paliad.* table with a project_id column — SELECT table_name FROM information_schema.columns WHERE table_schema = 'paliad' AND column_name = 'project_id'

Then DELETE FROM paliad.projects;

DO NOT touch: paliad.proceeding_types, paliad.deadline_rules, paliad.event_types, paliad.gerichte, paliad.checklists (templates), paliad.firms, public schema, auth schema.

Phase 2 — Seed (single transaction)

Write the seed in a Go script under scripts/seed-example-projects/main.go so it's reproducible. Use the suggested tree above as the contract. Each insert:

  • Generates a fresh UUID
  • Sets created_by to m's auth.users uuid (look up via SELECT id FROM auth.users WHERE email = 'matthias.siebels@hoganlovells.com')
  • Populates the relevant chain-code-driving fields: reference on client, opponent_code on litigation, patent_number on patent, proceeding_type_id on case
  • Sets path correctly per parent-child chain (existing trigger may do this automatically — verify)
  • Sets status='active', type per row

After seed: query paliad.projects and verify the BuildProjectCode helper produces the expected SIEMENS.HUAW.789.INF.CFI-style codes (just call the Go helper from the script and print).

Optional: also seed 1-2 sample deadlines per case (anchored to a near-future date) and 1-2 sample appointments — so the dashboard / inbox have something to show. Keep it minimal — main demonstration is the project tree + codes.

Phase 3 — Verify

  • Live on paliad.de (after deploy): open /projects → confirm tree renders + chain codes visible as second badge.
  • Open one of the UPC CFI projects → confirm the Schriftsätze tab + Verfahrensablauf show sensible defaults (since the proceeding_type is now properly set).

Hard rules

  • One transaction per phase — if either fails, rollback cleanly. No half-wiped state.
  • Don't touch reference tables (proceeding_types, deadline_rules, event_types, gerichte, checklists templates, firms).
  • The seed script must be re-runnable — wrap in BEGIN; DELETE FROM paliad.projects; INSERT ...; COMMIT; (or whatever cascade order works) so future test-data resets are one command.
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean (seed script must build).
  • Branch: mai/<worker>/test-data-reset-and-seed.
  • Run the actual wipe + seed against the live youpc Supabase from the head's machine via Supabase MCP (this is direct admin work; not deployed code). Or via the Go script invoked against DATABASE_URL. Document which approach in the completion report.

Out of scope

  • A general "seed mode" or "fixture loader" framework. This is a one-shot example seed. Future runs can adapt the script if needed.
  • Demoing every proceeding_type variant — pick a representative set, ~12-15 projects total.
  • Seeding test users / teams / firms (those persist independently).

Reporting

mai report completed with branch + SHAs + the resulting project tree (paste output of SELECT title, paliad_internal_build_project_code(id) FROM paliad.projects ORDER BY path or equivalent) + UX verification screenshot description.

## m's request (2026-05-25 14:15) > No that's good [re: project code semantics] — maybe we can delete our Test data and generate new ones? Some "Example Projects" with good settings? ## Current state (live) `paliad.projects` has **12 rows**, all created by m (matthias.siebels@hoganlovells.com). All are test data — references like `C-UPC-0001`, `L-2026-001`, `P-EP3456789`, no `opponent_code` set anywhere (which is why auto-derived chain codes don't render). Safe to wipe. ## Goal 1. **Wipe** the current 12 projects + every cascading row that references them. 2. **Seed** ~12-15 realistic patent-litigation projects that exercise the full auto-derived chain (Client.Litigation.Patent.Case → e.g. `SIEMENS.HUAW.789.INF.CFI`). 3. **Verify** the new chain codes render on /projects and project-detail headers. ## Suggested example tree (head's editorial — coder may refine) ### Client 1 — Siemens AG (reference: SIEMENS) - Litigation: Siemens ./. Huawei (opponent_code: HUAW) - Patent: EP3456789 — Funkkommunikationssystem mit Mehrfachantenne (patent_number: EP3456789) - Case: UPC CFI München — Klage Siemens ./. Huawei (proceeding_type: upc.inf.cfi) → `SIEMENS.HUAW.789.INF.CFI` - Case: UPC CFI München — Widerklage Huawei ./. Siemens (proceeding_type: upc.ccr.cfi, counterclaim_of the above) → `SIEMENS.HUAW.789.CCR.CFI` - Case: UPC CoA — Berufung Huawei (proceeding_type: upc.coa) → `SIEMENS.HUAW.789.COA` - Litigation: Siemens ./. Bosch (opponent_code: BOSCH) - Patent: EP1111222 — Sensoreinrichtung für autonomes Fahren (patent_number: EP1111222) - Case: LG München I — Klage Siemens ./. Bosch (proceeding_type: de.inf.lg) → `SIEMENS.BOSCH.222.INF.LG` - Case: LG München I — Klageerwiderung Bosch (defendant side perspective; proceeding_type: de.inf.lg) → `SIEMENS.BOSCH.222.INF.LG` ### Client 2 — Bayer AG (reference: BAYER) - Litigation: Bayer ./. Novartis (opponent_code: NOVA) - Patent: EP2222333 — Wirkstoffverbindung X (patent_number: EP2222333) - Case: EPA Einspruch (proceeding_type: ep.opp) → `BAYER.NOVA.333.OPP` - Case: DPMA Nichtigkeit (proceeding_type: de.nul.bpatg) → `BAYER.NOVA.333.NUL.BPATG` ### Client 3 — Beispiel AG (reference: BEISPL) *(intentionally sparse — demonstrates the empty-segment skip)* - Litigation: Beispiel ./. Wettbewerber (opponent_code: WTB) - Patent: DE10987654 (patent_number: DE10987654) - Case: DPMA Erteilungsverfahren (proceeding_type may be empty if not modelled) → `BEISPL.WTB.654` or similar Adjust the exact proceeding_type IDs to whatever `paliad.proceeding_types` has — query the table first; pick ones that produce nice `.code` tails. ## What to do ### Phase 1 — Wipe (write a single transaction) Figure out the full set of paliad.* tables that reference `paliad.projects(id)` via FK and delete dependents in dependency order. Likely set: - `paliad.deadlines` (anchors, actuals) - `paliad.appointments` - `paliad.party_assignments` (or whatever links parties to projects) - `paliad.parties` if they're project-scoped - `paliad.notes` - `paliad.events` / project_events audit feed - `paliad.team_memberships` - `paliad.checklist_instances` - `paliad.submission_drafts` - `paliad.custom_views` IF they were created tied to a project (likely user-scoped, leave them) - `paliad.approval_requests` - Any other paliad.* table with a `project_id` column — `SELECT table_name FROM information_schema.columns WHERE table_schema = 'paliad' AND column_name = 'project_id'` Then `DELETE FROM paliad.projects;` DO NOT touch: `paliad.proceeding_types`, `paliad.deadline_rules`, `paliad.event_types`, `paliad.gerichte`, `paliad.checklists` (templates), `paliad.firms`, public schema, auth schema. ### Phase 2 — Seed (single transaction) Write the seed in a Go script under `scripts/seed-example-projects/main.go` so it's reproducible. Use the suggested tree above as the contract. Each insert: - Generates a fresh UUID - Sets `created_by` to m's auth.users uuid (look up via `SELECT id FROM auth.users WHERE email = 'matthias.siebels@hoganlovells.com'`) - Populates the relevant chain-code-driving fields: `reference` on client, `opponent_code` on litigation, `patent_number` on patent, `proceeding_type_id` on case - Sets `path` correctly per parent-child chain (existing trigger may do this automatically — verify) - Sets `status='active'`, `type` per row After seed: query `paliad.projects` and verify the `BuildProjectCode` helper produces the expected `SIEMENS.HUAW.789.INF.CFI`-style codes (just call the Go helper from the script and print). Optional: also seed 1-2 sample deadlines per case (anchored to a near-future date) and 1-2 sample appointments — so the dashboard / inbox have something to show. Keep it minimal — main demonstration is the project tree + codes. ### Phase 3 — Verify - Live on paliad.de (after deploy): open /projects → confirm tree renders + chain codes visible as second badge. - Open one of the UPC CFI projects → confirm the Schriftsätze tab + Verfahrensablauf show sensible defaults (since the proceeding_type is now properly set). ## Hard rules - **One transaction per phase** — if either fails, rollback cleanly. No half-wiped state. - **Don't touch reference tables** (proceeding_types, deadline_rules, event_types, gerichte, checklists templates, firms). - The seed script must be **re-runnable** — wrap in `BEGIN; DELETE FROM paliad.projects; INSERT ...; COMMIT;` (or whatever cascade order works) so future test-data resets are one command. - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean (seed script must build). - Branch: `mai/<worker>/test-data-reset-and-seed`. - **Run the actual wipe + seed against the live youpc Supabase from the head's machine** via Supabase MCP (this is direct admin work; not deployed code). Or via the Go script invoked against `DATABASE_URL`. Document which approach in the completion report. ## Out of scope - A general "seed mode" or "fixture loader" framework. This is a one-shot example seed. Future runs can adapt the script if needed. - Demoing every proceeding_type variant — pick a representative set, ~12-15 projects total. - Seeding test users / teams / firms (those persist independently). ## Reporting `mai report completed` with branch + SHAs + the resulting project tree (paste output of `SELECT title, paliad_internal_build_project_code(id) FROM paliad.projects ORDER BY path` or equivalent) + UX verification screenshot description.
mAi self-assigned this 2026-05-25 12:16:59 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#87
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?