Vitruvyan Docs
Package Manager System Contract V1.0
Last updated: Feb 20, 2026 10:30 UTC
Status: Draft — Phase 5 Foundation
Scope: Vitruvyan Platform Package Management
Extends: UPDATE_SYSTEM_CONTRACT_V1
Purpose
This contract defines the Package Manager System for Vitruvyan Core, enabling installation, removal, and lifecycle management of:
- Services (microservices: api_babel_gardens, api_neural_engine, etc.)
- Sacred Orders (governance modules: orthodoxy_wardens, pattern_weavers, etc.)
- Verticals (domain applications: finance, healthcare, etc.)
- Extensions (plugins: MCP tools, exporters, adapters, etc.)
Non-negotiable principle: Package management must be declarative, transactional, and contract-driven.
1. Package Types & Taxonomy
1.1 Package Types
| Type | Identifier | Installation Method | Examples |
|---|---|---|---|
| Service | service | Docker Compose | api_babel_gardens, api_neural_engine |
| Order | order | Python package + migrations | orthodoxy_wardens, vault_keepers |
| Vertical | vertical | Manifest + contracts | vertical-finance, vertical-healthcare |
| Extension | extension | Optional dependencies | mcp-tools, prometheus-exporter |
1.2 Naming Convention
Pattern: <type>-<name> (lowercase, hyphen-separated)
Examples:
- Services:
service-babel-gardens,service-neural-engine - Orders:
order-orthodoxy-wardens,order-pattern-weavers - Verticals:
vertical-finance,vertical-healthcare - Extensions:
extension-mcp-tools,extension-grafana-exporter
Abbreviations (CLI shortcuts):
vit install babel_gardens→ resolves toservice-babel-gardensvit install orthodoxy_wardens→ resolves toorder-orthodoxy-wardens
2. Package Manifest Schema
File: packages/manifests/<package-name>.yaml
Required sections:
3. Dependency Resolution
3.1 Resolution Algorithm
- Parse manifest: Load package manifest from registry
- Topological sort: Build dependency graph (DAG)
- Version resolution: Find compatible versions for all dependencies
- Conflict detection: Check for incompatible packages (
conflicts_with) - Circular dependency check: Abort if cycle detected
- Generate install plan: Ordered list of packages to install
3.2 Version Constraints
Supported operators:
>=1.0.0: Minimum version<=2.0.0: Maximum version==1.5.0: Exact version~=1.2.0: Compatible release (>=1.2.0, <1.3.0)1.x.x: Wildcard (any minor/patch within major version 1)
3.3 Conflict Resolution
Conflicts arise when:
- Two packages require incompatible Core versions
- Package explicitly lists another in
conflicts_with - Two packages bind to same port
- Same service name in Docker Compose
Resolution strategy:
- Block installation: Display error message with conflict details
- Suggest alternatives: Recommend compatible package versions
- Manual override:
--forceflag (dangerous, discouraged)
4. Installation Methods
4.1 Docker Compose (method: docker_compose)
Steps:
- Parse
compose_servicefrom manifest - Verify service exists in
compose_file - Copy
.env.example→.env.<service>(if missing) - Prompt for required
env_requiredvariables - Update
docker-compose.yml(add service if missing) - Run
docker compose up -d <service> - Wait for health check (poll
required_endpoints) - Run
init_commands(if defined) - Run smoke tests
Example:
4.2 Python Package (method: pip)
Steps:
- Determine install command:
pip install <repository>@<version> - Run
pip install --no-deps <package>(avoid dependency conflicts) - Run database migrations (if
migrations_pathdefined) - Register in
.vitruvyan/installed_packages.json - Run smoke tests
Example:
4.3 Git Clone (method: git_clone)
Reserved for development/experimental packages.
Steps:
- Clone repository to
.vitruvyan/packages/<name>/ - Run setup script (if
setup_scriptdefined) - Register package
- Run smoke tests
4.4 Custom Script (method: script)
Escape hatch for complex installations.
Steps:
- Download installation script from
script_url - Verify checksum (SHA256)
- Execute script with
bash <script> install - Register package
- Run smoke tests
5. State Management
5.1 Installed Packages Registry
File: .vitruvyan/installed_packages.json
Schema:
Invariants:
- Updated after every
vit install/vit remove - Atomic writes (write to
.tmp→ rename) - Git-ignored (local machine state)
5.2 Rollback Support
Pre-install snapshot:
- Tag:
pre-install-<package>-<timestamp>(Git) - Backup:
.vitruvyan/backups/installed_packages_<timestamp>.json
Rollback triggers:
- Smoke tests fail
- Service crashes during startup
- User explicitly runs
vit rollback
Rollback procedure:
- Stop service (
docker compose stop <service>) - Restore Git state (
git checkout <tag>) - Restore
.vitruvyan/installed_packages.jsonfrom backup - Remove package files
- Update audit log
6. CLI Commands
6.1 Install
Output:
- Dependency tree
- Installation plan (packages, order, disk space)
- Configuration prompts (env vars, secrets)
- Progress indicators
- Success/failure summary
Exit codes:
0: Success1: Incompatible dependencies2: Installation failed3: Smoke tests failed (auto-rollback)
6.2 Remove
Safety checks:
- List dependent packages (block if any)
- Confirm data deletion (if
--purge) - Snapshot before removal
6.3 List
Output:
6.4 Info
Output:
- Package name, version, status
- Description, homepage
- Dependencies (tree view)
- Installation method
- Ports, volumes, env vars
- Configuration options
- Changelog (last 3 versions)
6.5 Search
Search fields: name, description, tags
7. Package Registry
7.1 Registry Location
Phase 5 (local manifests):
- Path:
vitruvyan_core/core/platform/package_manager/packages/manifests/ - Format: YAML files (one per package)
- Versioning: Git-tracked (part of Core repository)
Future (remote registry — Phase 6+):
- URL:
https://packages.vitruvyan.io/v1/ - API: REST (JSON responses)
- Cache: Local cache in
.vitruvyan/registry_cache/
7.2 Manifest Discovery
Search paths (in order):
- Local manifests:
vitruvyan_core/core/platform/package_manager/packages/manifests/ - User manifests:
.vitruvyan/custom_packages/ - Remote registry:
https://packages.vitruvyan.io/v1/(if configured)
7.3 Versioning & Channels
Channels:
stable: Production-ready releasesbeta: Pre-release testingexperimental: Development/unstable
Version format: SemVer X.Y.Z[-channel.N]
Examples:
1.2.0→ stable1.3.0-beta.1→ beta2.0.0-rc.2→ release candidate
8. Safety Guarantees
8.1 Pre-Installation Checks
- Compatibility: Core version, contracts version
- Dependencies: All required packages available
- Conflicts: No incompatible packages installed
- Resources: Disk space (100MB minimum), ports available
- Prerequisites: Docker running (if needed), databases accessible
8.2 Transactional Installation
Atomic operations:
- Git snapshot before install
- Backup
.vitruvyan/installed_packages.json - Rollback on any failure
Failure modes:
- Smoke tests fail → auto-rollback
- Service crashes → rollback + error report
- User Ctrl+C → rollback in progress (safe interruption)
8.3 Post-Installation Validation
- Smoke tests: Run package-defined tests
- Health checks: Poll HTTP endpoints
- Dependency verification: Check all dependencies loaded
- Stream connectivity: Verify Redis Streams working (services)
9. Integration with Update Manager
9.1 Unified CLI
Both systems use vit command:
9.2 Shared Components
Reused from Update Manager:
engine/registry.py→ Extended toPackageRegistryengine/compatibility.py→ Version matching (unchanged)engine/planner.py→ Reused for install plansengine/executor.py→ Extended toPackageExecutorci/contract_validator.py→ Package manifest validation
New components:
engine/package_resolver.py→ Dependency resolutionengine/catalog.py→ Package discoverypackages/manifests/→ Package manifest storage
9.3 Compatibility Enforcement
Package installation checks:
- Package
min_core_version≤ Current Core ≤max_core_version - Package
contracts_major== Core contracts major - All dependencies satisfy version constraints
Core upgrade checks:
- New Core compatible with all installed packages
- If incompatible → block upgrade OR suggest package updates
10. Versioning & Evolution
10.1 Contract Version
Current: PACKAGE_MANAGER_SYSTEM_CONTRACT_V1.0
Versioning policy:
- Major: Breaking changes to manifest schema
- Minor: Backwards-compatible additions
- Patch: Clarifications, typo fixes
Deprecation policy:
- 2 minor versions warning period
- 1 major version grace period
- Migration guide required for major changes
10.2 Manifest Schema Evolution
Backwards compatibility:
- New optional fields → default values
- Deprecated fields → ignored with warning
- Required fields → validation error
Migration tools:
vit migrate-manifest <package>→ Auto-upgrade manifest to latest schema
11. Implementation Phases
Phase 5 - Package Management Foundation (Weeks 7-8)
Deliverables:
- Contract published (this document)
- Package manifest schema defined
PackageRegistryimplemented (local manifests)DependencyResolverimplemented (topological sort)- 3 example packages created:
service-babel-gardensservice-neural-enginevertical-finance
Phase 6 - Install/Remove Commands (Weeks 9-10)
Deliverables:
vit installcommand workingvit removecommand workingvit listcommand working- Docker Compose integration
- State management (
.vitruvyan/installed_packages.json) - Rollback support
Phase 7 - Discovery & Catalog (Week 11)
Deliverables:
vit searchcommandvit infocommand- Local manifest discovery
- Tab completion for package names
12. Open Questions (To be decided)
- Remote registry: When to implement? URL structure?
- Package signing: GPG signatures for security?
- Multi-version support: Allow multiple versions of same package?
- Virtual environments: Isolate Python dependencies?
- Package namespaces: Support third-party packages (
@myorg/package)? - Upgrade strategy: How to upgrade packages independently of Core?
Appendix A: Package Manifest Examples
A.1 Service Package (Docker Compose)
See Section 2 (Babel Gardens example)
A.2 Order Package (Python + Migrations)
A.3 Vertical Package (Manifest + Contracts)
A.4 Extension Package (Optional Dependencies)
Appendix B: Dependency Resolution Example
Scenario: Install vertical-finance
Dependency tree:
Install plan:
- Install
service-pattern-weavers(1.1.0) - Install
service-neural-engine(2.1.0) - Install
vertical-finance(1.0.0)
Estimated time: 3 minutes (Docker pulls + smoke tests)
Appendix C: Error Handling
C.1 Incompatible Core Version
C.2 Missing Dependencies
C.3 Port Conflict
Changelog
v1.0 (Feb 20, 2026)
- Initial draft
- Package types defined (service, order, vertical, extension)
- Manifest schema specified
- CLI commands designed
- Integration with Update Manager defined
- Implementation phases outlined