Victus is under active development.
Most major technical subsystems now exist independently, but the complete personalized nutrition workflow is not yet integrated end-to-end.
The current challenge is no longer creating the basic architecture. It is connecting the existing systems into a reliable product path from user context and scientific evidence to personalized recommendations.
The current product can already authenticate users, persist conversations, log meals, display user data, execute an Agent conversation, process scientific papers, retrieve scientific claims experimentally, and deploy shared infrastructure.
However, these capabilities are not yet connected into the complete intended experience:
User
↓
Victus Web
↓
Victus Agent
↓
User Profile + Scientific Evidence + Nutrition Tools
↓
Personalized Recommendation
↓
Progress / Feedback
The product should therefore be considered a functional foundation with partial end-to-end integration.
| Capability | Status | Current State |
|---|---|---|
| Web application | Advanced / Partial | React + Hono + PostgreSQL product foundation is functional. Auth, persistent chat, food search, meal logging, profile and biometrics views exist. Several UX flows remain incomplete. |
| Conversational agent | Partial | Core LangGraph runtime is functional with safety, tool execution, clarification, confirmation, persistence, and memory boundaries. Active public tooling is still narrow. |
| Meal logging | Implemented / Partial integration | Meals can be captured through the Agent and through Fullstack. Fullstack meal delivery to Agent through the outbox is not yet implemented. |
| Authentication & identity | Implemented / Partial | Email/password product auth is implemented. Google login exists partially and still needs runtime validation. |
| User profile | Partial | Fullstack owns persistent profile, biometrics, and preferences. Agent-side profile capabilities are not yet fully exposed or synchronized. |
| Safety | Implemented foundation / Partial product maturity | Agent safety precheck and blocking flow exist. Safety remains an area that requires continued evaluation and policy refinement. |
| Scientific processing | Advanced | The scientific processing pipeline is one of the most mature subsystems. Its main role is producing structured scientific evidence for Retrieval. |
| Scientific retrieval | Experimental / Partial | Sparse, dense, hybrid/RRF retrieval and evaluation exist. The system is still CLI-first and is not yet a stable product service. |
| Scientific evidence in Agent | Missing integration | Retrieval is not yet connected as an active Agent capability. |
| Nutrition planning | Foundational / Planned capability | Some domain scaffolding and product UI exist, but there is no complete recommendation/planning workflow. |
| Personalized recommendations | Planned product milestone | Requires profile integration, scientific retrieval, nutrition tooling, and final recommendation orchestration. |
| Progress & feedback | Planned / Early foundation | Meal history exists, but adherence, progress interpretation, and recommendation adjustment loops are not yet implemented end-to-end. |
| Shared infrastructure | Advanced foundation / Partial operations | Runtime topology, deployment automation, networking, persistence, secrets and shared services are defined. Disaster recovery and operational verification remain incomplete. |
victus-agentRole: Conversational orchestration and controlled capability execution.
Status: Partial, functional runtime.
Implemented:
The active canonical tool catalog is currently limited to event_capture, focused on meal and beverage capture.
The repository contains additional domain structures and scaffolding, but their presence does not mean they are active capabilities.
victus-processingRole: Transform scientific papers into structured scientific evidence.
Status: Advanced development.
The processing system represents one of the strongest foundations in Victus.
Its architecture covers paper structuring, scientific evidence extraction, artifact generation, and downstream publication.
The intended downstream boundary is structured Canonical Evidence that Retrieval can index without redefining scientific meaning.
The remaining work is primarily around:
The core scientific processing problem is substantially further along than product integration.
victus-ragRole: Scientific evidence retrieval and ranking.
Status: Experimental / Partial.
The current repository is best described as a CLI-first retrieval and evaluation laboratory.
Implemented:
The currently verifiable complete path is primarily retrieval-oriented rather than product-oriented:
query
↓
retrieval
↓
ranked scientific claims
It does not currently generate final answers.
victus-processing;victus-agent;The key milestone is not more retrieval experimentation. It is completing:
Scientific Processing
↓
Scientific Retrieval
↓
Victus Agent
victus-fullstackRole: User-facing Victus web product.
Status: Advanced foundation / Partial product.
The current application architecture is:
Browser
↓
React / Vite
↓
Hono Backend
↓
PostgreSQL
└→ Victus Agent
Implemented:
Partial:
Some product areas remain demo representations rather than connected capabilities.
Examples include static evidence cards, nutrition-focus content, and chat trace displays.
Fullstack meal writes create a transactional meal_import_outbox entry, but there is currently no publisher delivering those events to Victus Agent.
Therefore:
Meal Log
↓
Fullstack PostgreSQL
↓
Outbox
↓
[delivery not implemented]
Chat is currently the primary active Fullstack → Agent integration.
victus-infraRole: Shared runtime infrastructure.
Status: Advanced foundation / Partial operational maturity.
The repository defines four primary Compose stacks:
core
observability
llm
wiki
Implemented and statically validated:
The main deployment model is:
GitHub Actions
↓
Infisical
↓
Ansible
↓
VPS
↓
Docker Compose
The repository is well defined, but the latest audit could not verify production health directly.
Important missing production-hardening capabilities include:
The current infrastructure protects reasonably against container restarts and redeployments, but not against complete VPS or disk loss.
victus-docsRole: Central architecture and ecosystem documentation.
Status: Active consolidation.
Wiki.js at wiki.victus.fit is the canonical documentation system.
The main system documentation is now organized around:
architecture/
system-context
containers
data-flow
systems/
scientific-processing
agent
retrieval
fullstack
infrastructure
Repository documentation should remain focused on implementation and operations.
The next documentation phase is consolidating only the shared cross-system contracts and ecosystem-level decisions that genuinely require a central source.
The main systems currently exist at different integration levels.
Fullstack ───────→ Agent
✓ chat boundary implemented
Processing ─────→ Retrieval
✗ current Canonical Evidence integration not complete
Retrieval ──────→ Agent
✗ not integrated
Fullstack Meals → Agent
~ outbox exists, publisher missing
This integration map is more useful than treating repository maturity as a single percentage.
Victus currently uses different environments according to workload and subsystem.
| Resource | Current Role |
|---|---|
| Development machines | Application development, local testing, experimentation, and CLI workflows. |
| Home compute | Scientific processing workloads and local experimentation where appropriate. |
| VPS / Hetzner | Shared Victus infrastructure runtime. |
| SeaweedFS | Shared S3-compatible object storage in the infrastructure stack. |
| External/versioned storage | Historical scientific artifacts and snapshots may also exist outside the active shared runtime depending on workflow. |
| PostgreSQL | Durable state across Fullstack, Agent, infrastructure services, and other subsystem-specific databases. |
| Qdrant | Current vector backend used by Retrieval when available; not currently part of victus-infra. |
The exact runtime source of truth for each subsystem remains its owning repository.
The previous priority list placed Safety first.
With the current system state, the highest-leverage work has shifted toward integration.
A practical order is:
Safety remains a cross-cutting requirement throughout these phases rather than a single isolated milestone.
The most important next milestone is:
A user asks Victus a nutrition question, the Agent retrieves versioned scientific evidence produced by Scientific Processing, combines it with relevant user context, and returns a grounded response.
Conceptually:
This milestone closes the most important architectural gap currently present in Victus.
The most important remaining gaps are:
The individual subsystems are ahead of the connections between them.
Retrieval needs to move from CLI-first experimentation toward a stable application boundary.
Retrieval needs to consume the current scientific evidence contract rather than older claim-oriented artifacts.
The product and Agent both have useful user-state foundations, but their ownership and synchronization paths need to be completed.
Meal capture exists, but the product still lacks the complete analysis, planning, recommendation, and adjustment workflow.
Infrastructure needs backup, restore, alerting, production verification, and better operational coverage.
Victus is no longer primarily an architecture prototype.
It contains real implementations for:
The central challenge is now system integration.
A useful summary is:
Individual foundations
✓
Cross-system contracts
~
End-to-end recommendation path
✗
Production hardening
~
The next stage of Victus development should prioritize completing one reliable vertical path rather than expanding the number of partially connected capabilities.