PRJ: domus-inventory
Project Summary
Project |
domus-inventory - Personal Asset Management |
Priority |
P2 - Medium |
Status |
Planned |
Owner |
Evan |
Language |
Python 3.11+ / Bash |
License |
MIT |
Location |
|
A grep-able, jq-queryable, insurance-ready inventory system following the plain text accounting philosophy. Single YAML source of truth with CLI tools for management and AsciiDoc pages for viewing.
Improvement Proposals
|
Proposals from ecosystem audit — 2026-04-04. For team review and prioritization. |
| Priority | Proposal | Rationale | Effort |
|---|---|---|---|
P1 |
Define data model (fields per asset) |
Currently in Planned status with no schema. Define: asset type, hostname, IP, MAC, serial, location, owner, purchase date, warranty, notes. |
S |
P1 |
Choose implementation approach |
Decide between: AsciiDoc table partial (simplest), CLI tool with YAML/JSON backend (automatable), or webapp with API (full-featured). |
S |
P2 |
Integration points with existing infrastructure |
Map how inventory data feeds into: Antora attributes (domus-infra-ops), DHCP reservations (pfSense), DNS records (BIND), monitoring (Prometheus). |
M |
P3 |
Automated discovery and sync capabilities |
Evaluate: nmap scans, SNMP walks, Ansible facts, ISE profiling data as sources for automated inventory population. |
L |
Implementation Approach Decision
| Approach | Pros | Cons | Recommendation |
|---|---|---|---|
AsciiDoc partial table |
Zero tooling, version-controlled, renders in docs |
Manual updates, no API, hard to query |
Good for < 50 assets |
CLI tool (YAML backend) |
Scriptable, version-controlled, queryable |
Requires development, learning curve |
Good for 50-200 assets |
Webapp with API |
Full CRUD, dashboards, integrations |
Heaviest development, hosting overhead |
Overkill until 200+ assets |
Design Document
Full schema and architecture details:
-
_drafts/inventory-system-design.adoc(Draft - TBD)