Investigate Documaster archive integration

Explore Documaster as a document/archive integration for Kaukus, not as the owner of committee and meeting workflows. Inputs: vendor email, archive structure diagram, and /home/mathias/Downloads/kaukus-api-validation.http. Scope: inspect supplied API contract, identify existing Kaukus abstractions to reuse, establish service authentication requirements, and validate read-only sample queries/downloads against the test API once credentials are available. Do not create archive folders, upload documents, or submit transactions without explicit agreement. Acceptance criteria: explain inbound document lookup and outbound meeting/protocol archiving; identify metadata/identity and retry questions; confirm necessary credentials and connectivity; record evidence and limitations from live read-only checks. Implementation is out of scope. Verified findings: vendor examples demonstrate OAuth client_credentials with client_secret_post; inbound Moetemappe lookup by refArkivdel.id + moetenummer, MI document lookup, Saksframlegg via mappeIdent + journalposttype S, and download via referanseDokumentfil; outbound Moetemappe creation plus upload and MP Moeteregistrering/Dokument/Dokumentversjon transaction. Example IDs are tenant-specific and should be discovered from responses, not hard-coded. Per-case decision archiving is mentioned but not demonstrated. Existing OAuth::ClientCredentialsClient can be reused; current meeting/case importers assume archive-owned meeting workflow, and existing SikriV2 protocol sync updates structured text rather than filing protocol PDFs. Public API docs: https://documaster.github.io/api-docs/general/authentication/ documents scope openid (confirm service configuration); https://documaster.github.io/api-docs/operations/core/query/ documents hasMore/offset pagination, optional sortOrder, and publicUse=true by default excluding screened entities. limit=1 examples do not establish uniqueness or select the latest document/variant. Screening/access rules require explicit validation before importing any confidential material. Connectivity verified using unauthenticated HEAD with normal TLS validation: token endpoint returns 405 Allow POST, OPTIONS; API query endpoint on port 8083 returns 401. No authentication, archive queries, downloads, uploads, or transactions performed. Service API validation remains blocked: client_id/client_secret and configured scope are not supplied; placeholders in the provided HTTP file are empty. User has requested service credentials from Documaster. Human login credentials are not required for the documented service flow. Additional scope: user supplied a local credential file for read-only UI exploration of the test archive. Two bounded browser explorations submitted the login and returned from IDP to /v2/; the follow-up observed page title Documaster. Post-login inspection returned no elements/text and raised TypeError: input.value?.slice is not a function. The isolated exploration tool did not expose alternate DOM evaluation, screenshots, console, or network inspection. This is an inspection tooling blocker, not verified evidence of an application rendering defect. No archive content was verified through browser automation. User subsequently supplied eight screenshots, providing the following UI evidence (not API validation): - Kaukus - Test contains Saksmappe 2026/6700, Moetemappe 6/2026 displayed with internal ID 8025301, and sample Moetemappe 7/2026 ID 8026499. - Folder 7/2026 shows primary class Kaukus - Funksjon / 1 Primary, meeting number 7/2026, committee Kaukus Board, date 24.09.2026, location Kaukus office, creator kaukus. It contains meeting record 8026730 of type MP - Møteprotokoll. - That record contains one PDF linked as Vedlegg, not Hoveddokument. Document metadata shows number 1, version 1, status B - Dokumentet er under redigering; preview is a generic Sample PDF. Record publication status and eInnsyn are Ikke publisert. No screening value is shown; this does not establish public access. No retention plan on folder or parent is reported. The vendor example uses tilknyttetRegistreringSom V, consistent with the visible attachment role. Confirm main-document role, finalization and publication requirements with vendor rather than treating example as production-ready archiving. - Folder access tab lists Service - Kaukus with effective LES + OPPDATER permissions; this does not verify the missing OAuth client's actual permissions. - Saksmappe 2026/6700 contains journalpost 2026/14312 (1), type I incoming document, and journalpost 2026/14313 (2), type S Saksframlegg, status J Journalført. The S title explicitly identifies 2. gangs behandling. Its one visible PDF is linked as Hoveddokument. Two follow-up screenshots verify a structured cross-reference: Saksframlegg journalpost 2026/14313 (2) displays 'Kryssreferert fra journalpost' linking to 8025544 PS 45/26 Detaljregulering for Fjordheim sentrum – bykjerne nord. Following it shows concrete UI type Moeteregistrering, ID 8025544, under parent [MM]:8025301 Formannskapet – møte 6/2026 (30.09.2026). Its 'Kryssreferanse til journalpost' links back to 2026/14313 (2). The meeting record has no own documents in the screenshot. Therefore the sample has a meeting-specific PS record linked to the case-file Saksframlegg; do not assume documents are physically duplicated into the meeting record or that the archive lacks all structured agenda associations. The UI's generic journalpost cross-reference label is not the concrete target entity type. Four further screenshots identify meeting record 8025544 as subtype D - Vedtak i møtesak, not a generic agenda entry. This materially limits any inference that these records are an authoritative agenda. The empty D record cross-referenced to the Saksframlegg suggests a possible case-decision archive destination, but whether to fill it versus create another record must be confirmed with Documaster. API relation names, completeness/order of agenda and export pattern for decisions remain unverified. - Design implication: distinguish archive case folder, selected journalpost/document, and Kaukus agenda item/treatment. Case number alone is not sufficient to identify a specific treatment or main/latest document when multiple saksframlegg/versions exist. Actual API object IDs still need query validation; displayed case/journal numbers are not substitutes. No archive mutations were performed. Further screenshots now cover the meeting folder, MI record/PDF and D record details; no further UI screenshots are needed for the initial structural investigation. Meeting 6/2026 folder 8025301 shows three records: PS45 (8025544), PS46 (8025391), and MI (8025305), sorted by creation date newest first (not agenda order). Folder metadata gives date 30.09.2026, committee Formannskapet - Civil Construction, and location Formannskapet. MI 8025305 has type MI - Møteinnkalling, meeting-case type PS - Politisk sak, and one PDF marked Hoveddokument. PDF preview lists six agenda entries (PS44, PS45, PS46, PS47, RS12, Eventuelt), time 09:00 and location Rådhuset, møterom Fjorden, 2. etasje. Thus two PS archive records do not cover the PDF agenda, and folder metadata does not reproduce all scheduling/location detail. Treat this as an observed sample mismatch, not proof of a universal product limitation. MI document is version 1 and status B under editing. Main unresolved product decision: identify the actual authoring system for committee meetings/agendas. User confirms this is also their central question: existing Sikri-style customers prepare upstream and import into Kaukus; Documaster may require another upstream application or Kaukus-owned preparation. Public product/support research confirms FirstAgenda Prepare supports both direct creation of meetings/agendas and importing agendas from a DMS. Management is separately positioned for complex secretariat agenda production, workflows/approvals, attendance and minutes, publishing into Prepare. Sources: https://www.firstagenda.com/en/prepare ; https://support.firstagenda.com/en/firstagenda-prepare/administrator/how-do-i-create-team ; https://www.firstagenda.com/en/management . Prepare is therefore a plausible authoring system, not merely a reader, but no Documaster-to-Prepare integration or supported third-party export to Kaukus was verified. Prepare-to-Live API exists using Client ID/Secret and administrator-selected teams; its documentation does not establish general third-party API availability (https://support.firstagenda.com/en/firstagenda-live/administrator/set-integrations-firstagenda-prepare). DMS import documentation describes explicit agenda XML, not reconstruction from archive files (https://support.firstagenda.com/en/firstagenda-prepare/agenda-producer-dms/which-information-your-document-management-system-does). Documaster's own integration directory lists DigDem by Jupiter as a political/elected-body meeting-administration system, providing a concrete example of another system occupying this layer: https://www.documaster.com/vaare-integrasjoner . It also lists Decisions for Teams meeting administration, which is not sufficient evidence of municipal political agenda authoring. DigDem's current vendor page could not be read beyond title via the web fetcher; exact authoring/export capabilities and any third-party interoperability were not verified. Do not imply these products are neutral middleware: they overlap with Kaukus's meeting functionality. Current recommendation: do not yet commit to expanding Kaukus into full saksframlegg drafting/approval workflow or a FirstAgenda integration. Ask Documaster/customer which system authors the actual intended customer's saksframlegg and complete ordered agenda, who publishes/freezes them, and what supported structured interface can supply them to Kaukus. The test archive's records/PDFs demonstrate storage, not the originating authoring workflow. If Kaukus owns only agenda assembly, separate that limited scope from full case preparation/approval. Service API checks remain blocked awaiting credentials. Also obtain vendor clarification on structured agenda data, D-record lifecycle, and meeting identity scope across committees. Document versions and confidential samples remain unverified. Service API checks still await credentials. Do not record credentials in tracking or repository content.