HIHome Inventory
GitHub
Roadmap

Design phase. No code yet.

The architecture is finished and stage 0 is being built against it. There is no release, no published container image and nothing to install today — the directories belonging to later stages are still deliberately empty. Contracts before implementations.

14architecture chapters, arc42-oriented
44decision records, each with its alternatives
4stages, each deployable on its own
0open decisions — the remainder is outstanding work

Four stages

No stage is half a product waiting for the next one. Each is usable and deployable on its own, and after each the remainder is re-assessed — the scope is large for one person, and that is a named risk rather than an optimistic silence.

Stage 0

MVP — capture and find

Next up

Done when: an item can be created, photographed, stored and found again — through a hardened instance reachable from the internet.

Included
  • ·Password login, sessions, rate limiting
  • ·Items with five fixed fields, and a location tree with fixed categories
  • ·Photos and documents: re-encoding, EXIF stripping, thumbnails, signed URLs — and the mandatory malware scan
  • ·Full-text search in PostgreSQL, cursor pagination
  • ·REST /api/v1 with OpenAPI and problem details
  • ·The web PWA, online
  • ·Both container runtimes rootless, migrations, health endpoints
  • ·All security foundations: row-level security, CSP, upload hardening, network segmentation
Not yet
  • ·Second factor, OIDC, invitations
  • ·The configurable type system
  • ·Notes and purchase data
  • ·OpenSearch, facets, saved searches
  • ·GraphQL, gRPC, webhooks
  • ·Offline operation
  • ·Helm, RabbitMQ
Stage 1

Core — configurable and multi-tenant

Planned

Done when: a tenant administrator sets up types, fields, location categories, tags and roles themselves — without a developer and without a restart.

The product
  • ·Item types and location categories with free fields, inheritance, versioning, generated JSON Schema
  • ·Tenants, memberships, invitations, roles, subtree scoping, field visibility, quotas
  • ·Second factor with TOTP and passkeys, session overview, service accounts
  • ·Lifecycle: warranty, maintenance log, lending, sale, disposal, trash, history with restore
  • ·Value reporting — purchase price, current value, replacement value, the insurance report
  • ·Import and export: CSV with mapping profile and dry run, Homebox and InvenTree profiles, GDPR access
The plumbing
  • ·JSONB attribute storage plus the index side table and its reconciliation
  • ·OpenSearch with facets and a PostgreSQL fallback
  • ·The transactional outbox, RabbitMQ, the worker role
  • ·The plugin runtime: registry, signed manifests, per-tenant capabilities, gRPC over mTLS, per-plugin network segments
  • ·First-party plugins: SMTP, S3, Nextcloud, webhook, OIDC
  • ·Audit log with a hash chain · metrics, tracing, backup with automated restore verification
Stage 2

Identification — label, scan, stocktake

Planned

Done when: a label sheet is printed, stuck on, scanned, and leads to the item — and a stocktake in the cellar works.

Codes and paper
  • ·The public short code: pre-issuing, binding, reassignment, resolution at /c/{code}
  • ·QR shipped, the CodeFormat port in place
  • ·Label templates with a bounded expression language
  • ·The label media catalogue with verification flags, start offset and a calibration sheet
  • ·The print job as an aggregate; PDF shipped, the PrintTarget port open
In the cellar
  • ·Browser camera with BarcodeDetector where the browser has it, ZXing-WASM everywhere else — including all of iOS
  • ·Continuous scan mode and HID handheld scanners
  • ·Foreign codes: EAN, UPC, ITF-14, ISBN
  • ·Stocktake mode with a discrepancy report
  • ·Moving mode with sealable mobile locations
  • ·The Helm chart, tested in CI against kind with a restricted profile
Stage 3

Ecosystem — open the contract, apps, offline

Planned

Done when: an external author, working only from the published SDK, gets a plugin running without a core change — and the app works a week offline and then reconciles without loss.

Opening up
  • ·home_inv.plugin.v1 is published and becomes binding under the six-month rule
  • ·SDKs for Java, Kotlin, Rust, Python and Go, the contract test suite, a project template, example plugins across those languages
  • ·Metadata enrichment: ISBN and EAN resolvers, the proposal model, field mapping
  • ·Further ports: printers, Bluetooth scanners, push channels, valuation providers
Apps and offline
  • ·Kotlin Multiplatform apps with Compose, OAuth 2.1 with PKCE, camera and scanner
  • ·Full bidirectional reconciliation with the three-way compare
  • ·Conflict records and their resolution, property-based tests
  • ·Device management with remote wipe, the media upload queue
  • ·The web PWA offline: IndexedDB, a service worker, local search

What has to come first

The order is not a preference. Each of these is a dependency that would have to be unpicked later at a much higher price.

Hard ordering constraints
FirstThenWhy
Type system (1)Metadata enrichment (3)Without target fields there is nothing to map onto
Type system (1)Offline validation (3)The client validates against the generated JSON Schema
Codes (2)Labels, stocktake, moving (2)Everything hangs on the code
Outbox and RabbitMQ (1)Plugin events (1)Plugins receive events
Plugin runtime (1)Invitations, password reset, remote storage (1)Mail and object storage are plugins
Change log (3)The apps (3)Without a reconciliation protocol there is no offline app

Deliberately deferred

Offline operation, GraphQL, OpenSearch, the published plugin contract, the Helm chart, the tenant interface. Each is cheap to add later and expensive to get wrong early.

Deliberately not deferred

Row-level security, the authorisation scaffolding, the content security policy, upload hardening, module boundaries with machine verification, multilingual support, cursor pagination, a trace id in every response — and rootless on both container runtimes. All of it is expensive later and cheap now.

The most useful thing you can do right now

Find a hole in the design. Before there is code, a wrong assumption costs a paragraph; afterwards it costs a migration. Issue templates exist for bug reports, feature requests, documentation and design feedback.