Add structured rule retrieval and version timeline commands #7

Norwegian law changes constantly, and the question "what did this rule say on the day the incident happened?" is a routine one in compliance and legal work. Lovdata keeps every historical version of a rule and can return the machine-readable structure of a document as it stood on a given date. From PowerShell there is currently no way to reach any of it, so answering a point-in-time question means reading a website and trusting a screenshot.

Request

Desired capability

Commands that list which versions of a rule exist, retrieve the structured form of a rule as it currently stands, and retrieve it as it stood on a specific date. Together these make it possible to script a point-in-time answer and to diff two dates of the same rule.

Acceptance criteria

• The available versions of a document can be listed with the dates each version applies from
• The structured form of a rule can be retrieved for the current version
• The structured form of a rule can be retrieved as of a given date
• The rules available in a legal source can be listed
• Asking for a date before the rule existed produces a clear message rather than an empty result
• Tests pass without an API key

References

• GET /v1/structuredRules/list and GET /v1/structuredRules/list/{base}
• GET /v1/structuredRules/get/{base}/{ruleFile} and its /{date} variant
• GET /v1/structuredRules/timeline/{base}/{ruleFile}

Technical decisions

Code placement: New group src/functions/public/StructuredRules/ with a StructuredRules.md overview.

Command naming: Get-LovdataStructuredRule for both the list and the single-rule cases, split by parameter set, and Get-LovdataStructuredRuleTimeline for the version list. The date is a parameter on the retrieval command rather than a separate command, because "the rule as of a date" is the same resource at another point in time.

Parameter sets: Prose-named sets — 'As the current version' and 'As of a date' — so Get-Help syntax reads naturally. -Date accepts [datetime] and is formatted for the API internally; callers never construct the API's date string.

Object model: LovdataStructuredRule and LovdataRuleVersion classes under src/classes/public/. The structured payload is nested, so the class exposes the document-level fields as properties and keeps the nested structure available rather than flattening it and losing information.

Error handling: A date with no corresponding version returns nothing from the API. Translate that into a clear terminating error naming the rule and the date, so a script does not silently proceed with no rule text.

Test approach: Unit tests mocking the transport, with a recorded-shape sample of a structured rule as test data under tests/.

Depends on: the load-bearing core in #2. The pull request targets build-lovdata-module.

Implementation plan

Core changes

• Add LovdataStructuredRule and LovdataRuleVersion classes under src/classes/public/
• Add Get-LovdataStructuredRule under src/functions/public/StructuredRules/
• Add Get-LovdataStructuredRuleTimeline under src/functions/public/StructuredRules/
• Add the StructuredRules.md group overview page

Tests

• Add a test for listing the rules in a legal source
• Add a test for retrieving the current version of a rule
• Add a test for retrieving a rule as of a date
• Add a test for the version timeline
• Add a test for a date with no matching version

Documentation

• Add a point-in-time example under examples/