مرکزی مواد پر جائیں

Capstone - Budget Tracker Complete App

You started this chapter with a script that couldn't handle a second user. Look where you are now: typed models, safe transactions, cloud deployment, independent verification. That's not a script anymore -- that's a system.

This lesson pulls every piece together. You will wire up your models, CRUD operations, transaction safety, Neon connection, and verification gate into a single application -- then run it end to end and collect the proof that it works.

Key Terms for This Lesson
  • Evidence bundle: A collection of test results that PROVES your system works -- not "I think it works" but "here's the proof it works"
  • Release gate: A checkpoint that must pass before your code goes to production -- if the gate fails, you stop and fix before shipping

The Integration Contract​

In Lesson 7, you built independent verification for high-stakes outputs. Now you combine every layer into one coherent application with six commitments:

  1. Models enforce schema (User, Category, Expense).
  2. CRUD paths include rollback on write failure.
  3. Summary queries avoid N+1 patterns.
  4. Neon connection uses pooled pre-ping configuration.
  5. High-stakes reports run independent verification before release.
  6. Semantic memory layer uses pgvector on the same Neon database, no separate vector store.

Each commitment maps to a lesson you already completed. The capstone is not new learning -- it is proof that all the pieces hold together under one roof.

You might be thinking: "Do I really need all these evidence gates?" For a toy project, probably not. For anything touching money, health data, or compliance? Absolutely. This evidence bundle pattern works for any system: e-commerce checkout flows, healthcare record systems, financial trading platforms.

The Evidence Pipeline​

Here is the sequence your capstone will follow. Each gate must pass before the next one runs:

Evidence Pipeline: six sequential gates from Schema through Vector to Release Decision, each must pass before proceeding

Five gates. One chain. If any gate fails, you stop and fix before continuing. No skipping ahead.

Sixth Gate: Semantic Memory

If your capstone includes the pgvector layer from Lesson 8, add a sixth gate after the Verify Gate:

Vector Gate: Direct the agent to run a similarity query on at least 3 sample expenses. Verify the top result matches your predicted semantic neighbor. Add the result to your evidence bundle under "vector_gate".

This gate is required if you completed Lesson 8. It is optional if you are working through the relational-only track.

PRIMM-AI+ Capstone: Make the Release Decision​

Predict [AI-FREE]​

Before you ask the agent to build or verify anything, write a release spec in your own words:

  • Which user and month you will verify.
  • Which evidence gates must pass.
  • What tolerance blocks release.
  • What status strings count as release-permitted vs release-blocked.
  • Your confidence score from 1 to 5 that the system will pass all gates.

Do not ask the agent until this release spec is written.

Run​

Directing the Monthly Summary​

Tell your agent to produce a grouped monthly summary using a single database call: no loops, no separate per-category queries.

What you tell the agent​

Generate Alice's January 2024 expense summary grouped by category, sorted by highest total first. Use one database call: no per-category loops. Return category name, expense count, and total for each group. Show the query count in the output so I can verify it used one call.

What you verify​

python run_summary.py

Output:
  Alice — January 2024:
  ┌─────────────────┬───────┬──────────┐
  │ Category        │ Count │ Total    │
  ├─────────────────┼───────┼──────────┤
  │ Housing         │   1   │ $1500.00 │
  │ Food            │   3   │  $287.45 │
  │ Transport       │   2   │   $94.20 │
  └─────────────────┴───────┴──────────┘
  Grand total: $1881.65
  Queries used: 1

"Queries used: 1" is the signal that matters. One database call produced the full grouped report. Compare that to the Computation & Data Extraction approach: nested loops, manual grouping, custom sorting: all doing what one SQL query handles natively.

Directing the Release Gate​

This is where "ready for demo" becomes "ready for release." Direct the agent to compare the SQL summary against the raw CSV ledger, using $0.01 as the mismatch tolerance.

What you tell the agent​

Verify Alice's January 2024 summary from two independent sources:

  1. The database (SQL path)
  2. The raw CSV ledger file (CSV path)

For each category, compare the totals. If any category differs by more than $0.01, block the release and show me the mismatch details with the category name, SQL total, CSV total, and the delta. If all categories match, output: status: verified.

What you verify​

python verify_release.py

Output (verified):
  Checking Alice — January 2024...
  Food:      SQL $287.45 | CSV $287.45 | ✓ match
  Housing:   SQL $1500.00 | CSV $1500.00 | ✓ match
  Transport: SQL $94.20 | CSV $94.20 | ✓ match
  {"status": "verified"}
  Release permitted.

Output (blocked):
  Checking Alice — January 2024...
  Food:      SQL $287.45 | CSV $287.95 | ✗ delta $0.50
  {"status": "blocked", "reason": "verification_mismatch",
   "tolerance": "0.01",
   "mismatches": [{"category": "Food", "sql": "287.45", "raw": "287.95", "delta": "0.50"}]}
  Release BLOCKED — investigate before shipping.

When you see BLOCKED, you do not ship. That is your engineering working correctly. Publishing despite a blocked status is a release process failure, not a query problem.

Compare both outputs to your release spec. If the output says blocked, your release decision is already made.

Investigate​

First, write your own explanation of why the release is permitted or blocked. Then ask the agent to trace the decision from requirement to SQL summary to raw verification to status. If the status is blocked, ask for the first three triage checks before editing any query logic.

Modify​

Change one release rule. For example, add the vector gate from Lesson 8, tighten the tolerance from $0.01 to $0.00, or require a forced rollback drill before the release gate. Predict whether the existing evidence bundle still passes. Then direct the agent to update the bundle and rerun the gate.

Make [Mastery Gate]​

Run the full capstone sequence below. This is the chapter's final Make task: you are not practicing one database primitive anymore; you are making an evidence-backed release decision.

The Evidence Bundle​

Your capstone produces one JSON artifact that captures every gate result:

{
  "crud_matrix": "pass",
  "rollback_failure_drill": "pass",
  "neon_connection_resilience": "pass",
  "verification_policy_result": "verified_or_blocked_with_reason",
  "vector_gate": {
    "status": "pass",
    "similarity_query": "find top 3 expenses similar to 'team meal'",
    "top_result": "team lunch with client",
    "distance": 0.18,
    "verified": true
  }
}

Capstone Run Sequence​

Run these seven steps in order. If any step fails, stop and fix before continuing:

  1. Create schema and seed deterministic fixture data
  2. Run CRUD matrix and capture outputs
  3. Run forced rollback drill and capture pre/post counts
  4. Run Neon connectivity health check
  5. Generate monthly SQL summary for one user
  6. Run independent raw verification for same user/month
  7. Evaluate mismatch policy and produce release decision artifact

This is deliberate sequencing. Step 3 proves your rollback actually works under failure. Step 6 proves your SQL output matches an independent source. Step 7 turns all of that into a decision artifact another engineer can read without asking you questions.

Gate Language​

When discussing readiness with your team, use precise language:

  • "Ready for demo" means the happy path passes
  • "Ready for release" means failure evidence and verification gate both pass
  • Never merge release candidates without the evidence bundle attached

The difference matters. A demo proves the system can work. A release proves the system can fail safely and recover correctly.

One Common Failure​

Publishing reports after a mismatch because "the SQL looks right." That is a release process failure, not a query bug. Another failure: claiming "production-ready" without failure-path proof. Passing only the happy path is insufficient for integrity claims.

Capstone Self-Review​

Before you call this done, answer these honestly:

  • Can another engineer rerun your evidence bundle without verbal guidance?
  • Are all critical thresholds explicit (the $0.01 tolerance, the blocked status rules)?
  • Did you demonstrate at least one failure path, not only success?
  • Could a reviewer trace from your requirement description to the agent's output to the evidence artifact quickly?
  • Did you describe requirements clearly enough that the agent built what you intended on the first try, or did you need to refine?

If any answer is "no," the capstone is still in progress.

Pause and Reflect

Look at what you've built across this chapter. In Lesson 0, you had a script that couldn't handle a second user. Now you have a cloud-deployed, transactionally safe, independently verified system. What's the single most important concept you learned along the way?

Computation & Data Extraction deliverable: one tax report for one person. Structured Data deliverable: a cloud-deployed, multi-user, transactionally safe, independently verified financial system. Same you. Different tools. Different capability.

Try With AI​

Prompt 1: Integrity Gap Audit​

Read my capstone code and classify each critical path:
- guaranteed by schema
- guaranteed by transaction
- guaranteed by verification policy
- still vulnerable
Return a prioritized fix list.

What you're learning: Classifying guarantees by type teaches you to distinguish between what the system prevents automatically (schema violations, partial writes) and what still requires your judgment (verification mismatches, edge cases). This is how experienced engineers think about production risk.

Prompt 2: Evidence Bundle Generator​

Generate a script that runs:
1) CRUD smoke checks
2) forced rollback drill
3) Neon SELECT 1 health check
4) verification gate run
Then outputs one JSON evidence bundle.

What you're learning: Automating your evidence collection turns a manual checklist into a repeatable script. This is the difference between "I checked it once" and "anyone can check it anytime." Automated evidence gates are the foundation of continuous deployment.

Prompt 3: Apply to Your Domain​

You're building [your project]. Design an evidence bundle with 4 gates:
1. What proves your data model is correct?
2. What proves your writes are safe?
3. What proves your cloud connection is reliable?
4. What proves your critical outputs are accurate?
For each gate, specify: what you test, what "pass" looks like, and what "fail" means.

What you're learning: Evidence-driven release decisions transfer to ANY software project. Whether you're shipping a mobile app, deploying an API, or publishing a report -- the pattern is the same: define gates, run tests, collect proof, make decisions based on evidence rather than gut feeling.

Your system is correct. But systems change. Users want new features. Schemas need to evolve. Data needs to migrate. Next chapter: how do you evolve a running system without breaking what works?

Checkpoint​

  • I ran the full capstone sequence: schema → CRUD → rollback drill → Neon health check → summary → verification gate → release decision.
  • I read the evidence bundle output and made an explicit release decision (verified or blocked).
  • I directed the agent through at least one failure path and read the rollback confirmation.
  • I can explain the difference between "ready for demo" and "ready for release" in one sentence.
  • My evidence bundle could be read by another person without me explaining what any of it means.

Flashcards Study Aid​