Implement apix-registry with IoT sunset/decommission lifecycle and full BDD suite

- REST API: register, patch, O-level, replacements, history, search endpoints
- IoT lifecycle validations: future sunset, lock-before-release, sunset-passed-before-decommission
- DB schema: Liquibase changesets 001–008 (services, versions, replacements, sunset-at column)
- @ColumnTransformer(write="?::jsonb") on bsm_payload fields to avoid JDBC varchar→jsonb rejection
- Jandex plugin on apix-common + quarkus.index-dependency so @NotBlank validators resolve at runtime
- quarkus-logging-json extension added; quarkus.log.console.json=false is now a recognised key
- Fix requireSunsetBeforeLockRelease: Boolean.TRUE.equals instead of !Boolean.FALSE.equals (null guard)
- BDD suite: 27 scenarios / 213 steps across 5 feature files (sunset-lock, decommission, replacement, discovery, anonymity)
- Test infrastructure: JDBC TRUNCATE in @Before for DB isolation, Arc.container() for clock control — no test endpoints in production code
- sunsetAt truncated to microseconds in BDD steps to match Postgres timestamptz precision
- Cucumber step fixes: singular/plural candidate(s), lastResponse propagation in replacementsReturnsNCandidates

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Carsten Rehfeld
2026-05-08 09:13:26 +02:00
commit b2a16a8be7
71 changed files with 5480 additions and 0 deletions
+23
View File
@@ -0,0 +1,23 @@
---
arc42: "12 — Glossary"
status: stub
---
| Term | Definition |
|---|---|
| **APIX** | API Index — the global, neutral, machine-queryable registry of services for autonomous agents |
| **BSM** | Bot Service Manifest — the structured metadata document that describes a machine-consumable service (capabilities, endpoint, trust level, pricing) |
| **Spider** | The automated APIX crawler that periodically checks liveness and spec compliance of registered services |
| **O-level** | Organisation trust level (O-0 to O-5). O-0: unverified. O-1: domain ownership confirmed. O-2: legal entity verified. Higher levels require additional compliance verification. |
| **S-level** | Service trust level. Reflects technical verification of the service against its declared BSM spec. |
| **Liveness** | Operational status of a registered service as last measured by the Spider. States: `pending`, `live`, `degraded`, `unreachable`. |
| **AE** | Agent Enterprise — an autonomous agent that composes APIX-registered services into a workflow and potentially earns on each execution |
| **HATEOAS** | Hypermedia as the Engine of Application State — REST architectural constraint where the client navigates entirely via links returned by the server; no out-of-band URL knowledge required |
| **DC-1** | Device Class registration — the APIX registration record for an IoT device class (BSM template); persists beyond the original operator's cloud service lifetime |
| **Capability** | A machine-readable tag describing what a service does (e.g., `inventory.read`, `slot.book`, `customs.doc`). The primary search dimension in APIX. |
| **GLEIF** | Global Legal Entity Identifier Foundation — the data source used for automated O-2 legal entity verification |
| **Internet-Draft** | `draft-rehfeld-bot-service-index-00` — the IETF submission that formalises the APIX specification |
| **PoC** | Proof of Concept — the MVP deployment described in this document |
| **STF** | Sovereign Tech Fund — the German federal funding body; primary target for APIX infrastructure funding |
| **BSF** | Bot Standards Foundation — the Swiss Stiftung that governs the APIX standard and operates the reference index |
| **UPSERT** | Insert-or-update DB operation — used for re-registration: same endpoint URL updates existing record rather than creating a duplicate |