Ship Lovdata's open, key-free API surface as the first release

[MariusStorhaug]

The Lovdata repository was created from PSModule/Template-PSModule and still contains template scaffolding. Anyone installing it today gets a placeholder command and no way to reach Lovdata, the foundation that maintains the authoritative body of Norwegian law.

Request

Desired capability

Lovdata publishes a set of open datasets and service endpoints that need no account at all: the current acts and central regulations as downloadable packages under NLOD 2.0, plus the endpoints that report whether the service is up and which build is deployed. That open surface is what most people can actually use without a commercial agreement, and it is what the first release covers.

A PowerShell user should be able to install the module and pull the full corpus of Norwegian acts in two commands, with nothing to configure and no credential to obtain. Everything behind an API key is deliberately out of scope here and tracked in #15.

Acceptance criteria

• The module installs and every command works with no account, no key, and no configuration
• The available open data packages can be listed, with the size and last-modified date needed to decide what to download
• A package can be downloaded to a chosen location, with progress, and without silently overwriting an existing file
• Service reachability and the deployed API version can be checked
• The NLOD 2.0 licence and the requirement to credit Lovdata are visible where a user will meet them
• A failed call explains itself in the module's own words rather than as a raw HTTP failure
• The test suite passes without network access to Lovdata

References

• Lovdata API reference and the OpenAPI document
• About the API service — the open site versus Lovdata Pro
• Lovdata's open data announcement
• Open endpoints, confirmed against the live service: /v1/publicData/list, /v1/publicData/get/{filename}, /ping, /version, /apichanges, /privacy

---

Technical decisions

Scope of the first release: The open surface only. The API key mechanism, the credential store, and every command that needs one are deferred to #15. This keeps the first release usable by anyone rather than only by holders of a Lovdata api role, and avoids shipping a credential store that nothing consumes.

Release type: Minor. The first release is 0.1.0 rather than 1.0.0, because the authenticated surface is not covered yet and 1.0.0 should mean the module wraps the API rather than a part of it.

Bootstrap branching: Follow module bootstrap. One long-lived integration branch, build-lovdata-module, cut from main. This issue covers the branch merging into main as the first release; individual command groups target the integration branch.

Archetype: Integration (API) module per Module types. Commands are named after the resource and intent with the Lovdata noun prefix.

State: Module-wide settings, principally the API base URI, live in a module-scoped variable for the session. No Context dependency in this release: Context exists to encrypt secrets at rest, and this release has no secret. It returns with the credential store in #15.

Transport abstraction: Private. Invoke-LovdataAPI under src/functions/private/API/ owns the concrete HTTP call, query-string building, and error translation. It is written so that adding key injection later is an addition to one helper rather than a second transport path.

Rate limiting: The service applies a limit to unauthenticated callers too — X-RateLimit-Limit: 200 is returned on the open endpoints — so the transport surfaces the remaining budget on the verbose stream from the first release.

Error handling: The API returns RFC 9457 style problem documents. The transport reads the status code without throwing, then raises a terminating error carrying the API's own message and detail, with dedicated guidance for 429.

Test approach: Unit tests mocking the module-owned transport boundary. No live calls in the unit suite, so the tests pass offline.

Repository baseline: The template is missing several files required by Repository defaults. They are added as part of this bootstrap rather than deferred.

---

Implementation plan

Repository

• Remove the scaffold function, test, and example, and replace every {{ NAME }} / {{ DESCRIPTION }} token
• Rewrite README.md to the Repository-Defaults shape, including the NLOD 2.0 attribution
• Add SECURITY.md, SUPPORT.md, CODE_OF_CONDUCT.md, and .github/pull_request_template.md
• Confirm .github/PSModule.yml only overrides defaults where this module needs different behaviour
• Rewrite the README around the key-free surface

Core

• Add src/variables/private/Lovdata.ps1 holding the module defaults
• Add the LovdataConfig class and the Get-LovdataConfig / Set-LovdataConfig commands
• Add Invoke-LovdataAPI under src/functions/private/API/
• Remove the credential store, the authenticated transport path, and Get-LovdataLegalSource, and recover them under Add the authenticated Lovdata API surface in a later release #15
• Add access to Lovdata's free open data packages #9 — open data package listing and download
• Add service reachability, API version, and account commands #8 — service reachability and API version

Tests and examples

• Add Pester coverage that runs without network access
• Rework the suite around the key-free surface
• Add realistic scenarios under examples/

Follow-up

• File issues for the command groups that need an API key, under Add the authenticated Lovdata API surface in a later release #15

[MariusStorhaug]

Rescoped the first release to Lovdata's open, key-free surface.

• Section 1 now describes the open data packages and service endpoints rather than the credential store. The user-facing promise changed from "store a key once" to "works with no account at all", which is a different capability and needed rewriting rather than trimming.
• Section 2 records the decisions behind that: no Context dependency in this release, since Context exists to encrypt secrets at rest and this release has no secret; the transport is written so key injection is a later addition to one helper rather than a second path; and the release is a minor bump, so 0.1.0 rather than 1.0.0, because 1.0.0 should mean the module wraps the API rather than a part of it.
• Section 3 marks the repository and transport work already done, and adds the removal of the credential store, Resolve-LovdataContext, and Get-LovdataLegalSource from this branch, plus the rework of the README, tests, and examples around the key-free surface.
• Everything that needs an API key moved under Add the authenticated Lovdata API surface in a later release #15, which links the command-group issues already filed. The credential store implementation is not lost: it is recoverable from the history of build-lovdata-module, and Add the authenticated Lovdata API surface in a later release #15 says so rather than asking for it to be written twice.
• Add service reachability, API version, and account commands #8 and Add access to Lovdata's free open data packages #9 were filed as follow-ups for a later release; both are entirely key-free, so they move into this one and are now listed here.

Also confirmed against the live service rather than trusting the OpenAPI document alone: /v1/publicData/list, /ping, and /version all answer 200 with no credential, and the open endpoints return X-RateLimit-Limit: 200, so rate-limit surfacing is worth keeping from the first release.

No open questions.