docs: add validated CVP IS basic search route
Validate skill / validate (push) Failing after 8s

This commit is contained in:
2026-08-19 07:42:35 +00:00
parent fd33a2144a
commit 9de0e702f4
2 changed files with 20 additions and 2 deletions
+18 -2
View File
@@ -1,8 +1,24 @@
# CVP IS organization-first procurement discovery
Use this route as an additional discovery path for Lithuanian public-procurement evidence. It is not a complete procurement history.
Use these routes as additional discovery paths for Lithuanian public-procurement evidence. They are not a complete procurement history.
## Validated route
## Validated basic procurement search
The live advanced-search endpoint accepts a URL-encoded contracting-authority query and returns an HTML results table:
`https://viesiejipirkimai.lt/epps/viewCFTSAction.do?mode=search&isFTS=true&type=cftFTS&isPopup=false&contractAuthority=<URL-encoded client name>&...`
Keep the remaining advanced-search fields present and empty when reproducing the browser form unless intentionally filtering them. The actual query key is `contractAuthority` (not `contractingAuthority`). Encode spaces as `+` or `%20` and Lithuanian characters as UTF-8 percent escapes.
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.
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.
## Validated organization-first route
1. Open `https://viesiejipirkimai.lt/epps/viewOrganisations.do` and search the exact client legal name, then former-name and abbreviation variants where needed. The live organization form uses `POST /epps/viewOrganisations.do` with lowercase field names, including `within=template.group.ca`, `name=<exact legal name>`, and optional `shortName`, `city`, and `street`; preserve the session cookie and normal referrer when reproducing the form request. Do not invent a GET query parameter or capitalize `name` from the input element's `id="Name"`. If a byte-exact authoritative name yields no row, retry only bounded typography/legal-form variants such as removing Lithuanian quotation marks or using the portal's likely `AB`, `VšĮ`, or expanded legal-form rendering. Record which query matched.
2. Identity-check the returned legal name and available profile details. Parse complete organization-result table rows and bind each displayed legal name to the `prepareViewCAOrganisation.do?id=...` link in that same row. Do not collect every profile link from a wide HTML context and then substring-match the query: one result page or surrounding fragment can contain multiple organization/profile links, producing a false “exact” match or an ambiguous pair. Preserve the query variant, portal-displayed organization name, registration number/domain when available, and organization ID. If an exact-name query still yields multiple distinct exact rows, keep the identity unresolved until registration number, domain, or another authoritative identifier distinguishes them; never select the first result. A variant match is discovery only until reconciled with the authoritative client identity. Treat near-identical domains as a collision risk: open the homepage and corroborate its institution name/contact domain against the CVP IS profile before using any system link found there.