vssa-v1-skills-code-agent/vssa-clients
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: deduplicate CVP IS rows by resource ID
Validate skill / validate (push) Successful in 4s
Details

Browse Source
This commit is contained in:
jarvis-at-skic
2026-09-01 20:11:57 +00:00
parent 8329b6aaff
commit 53923ee180
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
references/cvp-is-organization-route.md
+1 -1
View File
@@ -13,7 +13,7 @@ Keep the remaining advanced-search fields present and empty when reproducing the
1. Search the exact authoritative client name first. A partial legal-name substring is supported as a discovery fallback, but it can broaden results and must not be treated as identity evidence.
2. Require HTTP success and HTML content, then parse complete result-table rows. The live table exposes basic fields including procurement title, procurement ID, contracting authority, publication date, submission deadline, procedure, status, winner-selection date when present, and estimated value.
3. Compare the contracting-authority cell in every retained row against the intended VSSA client. Preserve exact names and reject near-name or parent/subordinate-authority collisions rather than assuming that the search input scoped every result correctly.
4. Follow all result pages. Derive pagination from the returned HTML or its `writePageSelection(...)` call rather than hard-coding a table identifier or page count. On the validated basic-search response, the first `writePageSelection("<N>", "...d-<table-id>-p=...")` argument is the **last page number/page count**, not the number of result rows; request pages `1..N` using the live `d-<table-id>-p` key and de-duplicate complete rows. Do not divide that argument by the visible page size—a client with `writePageSelection("23", ...)` exposed 229 rows across 23 pages, not three pages derived from an assumed 230-row total.
4. Follow all result pages. Derive pagination from the returned HTML or its `writePageSelection(...)` call rather than hard-coding a table identifier or page count. On the validated basic-search response, the first `writePageSelection("<N>", "...d-<table-id>-p=...")` argument is the **last page number/page count**, not the number of result rows; request pages `1..N` using the live `d-<table-id>-p` key and de-duplicate procurements by their `resourceId`. Do not hash the complete rendered row as the identity key: the same procurement can recur on another page with a different display ordinal and otherwise identical business fields. Do not divide that argument by the visible page size—a client with `writePageSelection("23", ...)` exposed 229 rows across 23 pages, not three pages derived from an assumed 230-row total.
5. Treat the HTML table as discovery metadata only. Open the procurement record and its relevant notice/attachment, classify the body and procurement stage, and cite the direct supporting page or document before mapping a system, supplier, contract, delivery, hosting, or completion claim.
Live validation on 2026-08-19 used both `Lietuvos Respublikos Vyriausybės kanceliarija` and partial `Vyriausybės kanceliarija`. Each returned HTTP `200` HTML, the same `39` total rows, and authority cells displaying the exact full legal name. The first page exposed ten rows, including IT-relevant titles, confirming that this route is useful for current-procurement discovery but still requires row-level identity and body-level stage checks.