Skip to content

LastVet — Agent Orientation (Phase 1)

You are building LastVet Phase 1. This file orients you. The always-apply rule .cursor/rules/00-invariants.mdc holds the non-negotiables; this file explains them. PARKED.md is the do-not-build list. /gates/* are the build specs — work only the current gate.

What LastVet is

A veteran-owned health-data sovereignty + coordination platform. The veteran owns their data; LastVet is the layer between providers, not another EHR. Phase 1 scope lock remains mental-health care coordination in San Diego (two VA APIs + Facilities/Forms). The operating wedge today is Warriors in Need (WIN) / job_placement on last1.app — org onboarding, attestation, enrollment lifecycle, accountability metrics — running in parallel with Gate 0.5 proof work, not instead of it.

The Phase 1 product (one sentence)

A verified, sovereign veteran health-and-service profile — owned by the veteran, verifiable by a trusted org, shareable with consent. If a feature needs an API we don't have, it is not Phase 1.

Production topology (R940 — assume unless told otherwise)

Canonical detail: docs/security/POSTURE.md, docs/architecture/R940_PLATFORM_ARCHITECTURE.md.

  • LastVet API: api.last.vet → lastvet-edge → lastvet-api (VM 107) → lastvet-db (VM 108). Not AWS ECS.
  • last1.app: monolith on last1app-app (VM 104); edge stack on last1app-db (VM 103); public api.last1.app.
  • last1.id: auth.last1.id (GoTrue / OIDC spine).
  • AWS ECS + RDS and Railway: rollback/teardown nets only — never the target for new deploys, Gate 0 proof, or prod reads.

Coordination engine (where the loop lives)

Org coordination loops, enrollment disposition, org accountability dashboard, and attestation ledger are owned by last1.app (LOOP1_COORDINATION_ARCHITECTURE.md). LastVet is the veteran read + attest surface (verification, DD-214 vault, ROI/consent, coordination nudges). Do not recommend "sync outcomes to last1.app" — last1.app is the system of record for org loops. LastVet-native ROI/consent proof events may still live in lastvet-api Postgres (Gate 0 spine).

Current build state (assume unless told otherwise)

  • VA Lighthouse APIs — sandbox approved (June 2026): Patient Health API (FHIR) and Veteran Service History & Eligibility. OAuth client IDs are in last.vet-ios/LastVet/Core/Auth/VAAuthConfig.swift; redirect URI https://last.vet/oauth/callback. Production access still pending — build and demo against sandbox until then.
  • Open-data APIs (no veteran auth, buildable now): Facilities, Forms.
  • Already built: two-data-plane architecture (VA data fetched with consent, held transiently; tokens in keychain, not on server; encrypted store for veteran-directed copies) and 42 CFR Part 2 handling.
  • Loop #1 / WIN (live pilot): org programs on last1.app, last1.id verification reads, enrollment qualify/remove/reactivate, org accountability metrics (incl. screening vs attrition §10.10), demo-org prod probes. See docs/architecture/LOOP1_BUILD_PLAN.md.
  • Operating System mechanics (Radio Check, Missions, Status/Progress): Gate 1 veteran-side frequency engine — not the WIN wedge blockers.

The Coordination Note (the core boundary)

  • IS: a veteran-owned, cross-provider summary written to be seen by the next provider and the veteran.
  • IS NOT: a billable progress note, treatment plan, or assessment — those stay in the provider's EHR.
  • HOW IT'S MADE (MH Gate 2 path): wherever the provider runs an API-reachable EHR, auto-derive the coordination-relevant, veteran-visible subset via that EHR's FHIR API. Manual entry is fallback only. Not required for WIN/job_placement loops.

How the gates work

Build only the current gate. Each has a Definition of Done tied to a proof milestone, and unlocks exactly one next thing. Do not pull work forward. Gate order: 0 → 0.5 → 1 → (1.5 conditional) → 2 → 3. See /gates.

Active gate: GATE_0.5 — proof, ops, security, IA hygiene on R940 prod. Gate 0 earn line = Facilities + ROI E2E on api.last.vet, not AWS. Gate 1 OS mechanics wait for 0.5 exit (sandbox build does not wait on VA prod approval).

Parallel tracks (not substitutes for the active gate): Loop #1 / WIN on last1.app; Meridian M-gates; SD mental-health org list in GATE_1_TRACTION_THRESHOLD.md §6b (Phase 1b, not the only motion).

Non-negotiables (also in the always-apply rule)

  1. Scope lock to the two APIs + Facilities/Forms (MH Phase 1); WIN uses service verification, not FHIR.
  2. Gates earned, not scheduled.
  3. Coordination layer, not an EHR.
  4. Two-data-plane + Part 2 + no financial inducement to veterans.
  5. Partner mindset: don't auto-agree, name scope creep, smallest change, read before acting.

Tone

Direct. When something looks like scope creep or an everything-app pull, say so before building it.

Design references (added July 2026; updated September 2026)

  • LOOP1_COORDINATION_ARCHITECTURE.md — canonical for where the org loop engine + ledger live (last1.app). Read before any coordination/ledger work.
  • LOOP_LEDGER_AND_PROOF_MACHINE_SPEC.md — Gate-mapped proof surfaces; LastVet ROI/consent spine + read surfaces. Org loop SoR = last1.app (see §1 redirect in that doc).
  • THE_RETURN_PATH.md — design law for every veteran-facing surface: no signal without a designed return; one clock (Radio Check cadence); beneficiary surface renders first.
  • gates/HORIZON_CROSS_ECOSYSTEM_VERIFICATION.md — WIN pilot LIVE (org loop + verification on last1.app / last1.id / LastVet). Full LastVet grant card + related-party arm's-length paper = still gated post-Gate 2. Not "unbuilt."
  • gates/meridian-implementation-spec-pointer.md — canonical Meridian implementation specs live in last1-meridian.
  • MERIDIAN_GATES_PARALLEL_TRACK.md — parallel track, not a gate.
  • CRISIS_PROTOCOL.md — verbatim crisis handoff; Section 2 buildable now; Section 3 blocklist gates m1_eligible.

Not build instructions

Business/strategy documents (premortem, term sheets, LOIs, convening plans, IP_ACTION_PLAN.md) may exist in the workspace for Ryan's use. They are context, NOT specs. Never derive build tasks from them; specs come only from gates/ and the design references above.