In this task, I understood the Durability property of ACID using a wallet system. Durability means that once a transaction is committed, the data will be permanently stored in the database and will not be lost even if the system crashes or restarts.

First, I created the accounts table.

CREATE TABLE accounts (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
balance INT NOT NULL CHECK (balance >= 0),
last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
Then I inserted sample data.

INSERT INTO accounts (name, balance)
VALUES
(‘Alice’, 1000),
(‘Bob’, 500);
To check the initial data:

SELECT * FROM accounts;
Alice had 1000 and Bob had 500.

Next, I performed a successful transaction to transfer 300 from Alice to Bob.

BEGIN;

UPDATE accounts
SET balance = balance – 300
WHERE id = 1;

UPDATE accounts
SET balance = balance + 300
WHERE id = 2;

COMMIT;
After committing, I checked the data again.

SELECT * FROM accounts;
Now Alice had 700 and Bob had 800.

Then I simulated a system restart by reconnecting to the database and checked the data again.

SELECT * FROM accounts;
The values remained the same, which shows that the committed transaction was permanently saved.

If a failure happens before COMMIT, the changes are not saved.

BEGIN;

UPDATE accounts
SET balance = balance – 200
WHERE id = 1;

— crash before COMMIT
After restart, the balance remains unchanged.

If a failure happens after COMMIT, the data is already stored and will not be lost.

This happens because PostgreSQL uses Write-Ahead Logging (WAL), which ensures that committed data can be recovered even after a crash.

From this task, I understood that Durability ensures that once a transaction is completed, the data remains safe and permanent. This is very important in wallet systems to prevent loss of money or incorrect balances.

Step 1: Check initial data
SELECT * FROM accounts;

Explanation:
Alice has 1000 and Bob has 500.
Both balances are valid (not negative).

Step 2: Try to make balance negative directly
UPDATE accounts
SET balance = -100
WHERE name = ‘Alice’;

Explanation:
Here I am directly trying to set a negative balance.

What happens:
Query fails

Reason:
There is a constraint CHECK (balance >= 0)

So database itself prevents invalid data.

Step 3: Deduct more than available balance
UPDATE accounts
SET balance = balance – 1500
WHERE name = ‘Alice’;

Explanation:
Alice has only 1000 but I tried to deduct 1500.

What happens:
Query fails

Reason:
Result becomes negative, so CHECK constraint blocks it

Step 4: Valid deduction
UPDATE accounts
SET balance = balance – 500
WHERE name = ‘Alice’;

Explanation:
This works because balance remains positive.

Step 5: Using transaction (important case)
BEGIN;

UPDATE accounts
SET balance = balance – 1200
WHERE name = ‘Alice’;

COMMIT;

Explanation:
Here also it fails before commit.

What happens:
Transaction does not complete

Reason:
Constraint is checked during update

Step 6: Application-level check (manual condition)
UPDATE accounts
SET balance = balance – 1200
WHERE name = ‘Alice’
AND balance >= 1200;

Explanation:
Here I added a condition to avoid wrong deduction.

What happens:
No rows updated

Reason:
Condition fails, so query is safe

Final Understanding
Database constraint (CHECK balance >= 0) prevents invalid data
It stops negative values automatically
This is schema-level protection

But,

Checking enough balance before deduction should also be handled in query or application
Otherwise transaction may fail

I tested different updates and observed that database constraints prevent negative balances. I also understood that some validations should be handled in queries or application logic to avoid errors.

“The Saturn V flew thirteen times. Not thirteen slightly different rockets — thirteen instances of a single masterpiece, each adjusted only by the precise mission parameters it was given. The blueprint was constant. The mission was the variable.”

🌕 Episode 3 — The Blueprint (Variables & Outputs)

There is a species of creature in the engineering world that fascinates and troubles me in equal measure.

It is the hardcoded configuration.

You find it everywhere — lurking deep in .tf files, sometimes in configuration files, occasionally even in shell scripts committed to public repositories with AWS access keys in them (a horror I shall not dwell on here). This creature has one defining characteristic: it cannot adapt. It knows only one environment. One region. One instance size. One mission.

Change any parameter and the whole thing shatters.

The Saturn V engineers understood that missions would vary. The payload changes. The trajectory changes. The launch window changes. But the rocket — the design of the rocket — stays constant. You change the parameters, not the blueprint.

This is the purpose of Terraform Variables.

🔧 Input Variables: The Mission Parameters

An Input Variable is a parameter that makes your Terraform code reusable across missions. Instead of hardcoding "us-east-1" in twenty places, you declare a variable called region and use it everywhere.

When you want to fly to a different launch site, you change one parameter. Not twenty values scattered through three files.

# variables.tf — The Mission Parameter Sheet

# Where are we launching from?
variable "aws_region" {
  description = "The AWS region where mission infrastructure will be deployed"
  type        = string
  default     = "us-east-1"   # Cape Canaveral is the default

  validation {
    condition     = can(regex("^[a-z]{2}-[a-z]+-[0-9]$", var.aws_region))
    error_message = "Region must be a valid AWS region code (e.g., us-east-1, eu-west-1)."
  }
}

# What is this mission called?
variable "mission_name" {
  description = "The name of this mission. Used to tag all resources."
  type        = string

  validation {
    condition     = length(var.mission_name) >= 3 && length(var.mission_name) <= 20
    error_message = "Mission name must be between 3 and 20 characters."
  }
}

# What environment are we operating in?
variable "environment" {
  description = "The operating environment: simulation, staging, or production"
  type        = string
  default     = "simulation"

  validation {
    condition     = contains(["simulation", "staging", "production"], var.environment)
    error_message = "Environment must be 'simulation', 'staging', or 'production'."
  }
}

# What size spacecraft do we need?
variable "instance_type" {
  description = "The EC2 instance type for the lunar module compute"
  type        = string
  default     = "t3.micro"
}

# How many crew members? (How many instances to run)
variable "crew_count" {
  description = "Number of compute instances to launch"
  type        = number
  default     = 1

  validation {
    condition     = var.crew_count >= 1 && var.crew_count <= 10
    error_message = "Crew count must be between 1 and 10. We are not launching an army."
  }
}

# Mission configuration map — structured parameters as a complex type
variable "mission_config" {
  description = "Mission configuration object"
  type = object({
    enable_monitoring = bool
    backup_retention  = number
    allowed_cidrs     = list(string)
  })
  default = {
    enable_monitoring = true
    backup_retention  = 7
    allowed_cidrs     = ["10.0.0.0/8"]
  }
}

🔤 Variable Types: The Classification of Parameters

Variables in Terraform are typed. This is not pedantry — it is the same discipline that kept the Saturn V from exploding because someone mixed up imperial and metric units. (That particular horror belongs to a different programme.)

# The full catalogue of Terraform variable types:

variable "example_string" {
  type    = string
  default = "Houston, we have a configuration"
}

variable "example_number" {
  type    = number
  default = 42
}

variable "example_bool" {
  type    = bool
  default = true
}

variable "example_list" {
  type    = list(string)
  default = ["Armstrong", "Aldrin", "Collins"]
}

variable "example_map" {
  type    = map(string)
  default = {
    commander = "Armstrong"
    pilot     = "Aldrin"
    module    = "Collins"
  }
}

variable "example_set" {
  type    = set(string)
  default = ["us-east-1", "eu-west-1"]
}

variable "example_object" {
  type = object({
    name        = string
    crew_size   = number
    is_crewed   = bool
    destinations = list(string)
  })
}

📁 Variable Values: The Mission Assignment

Declaring a variable is like designing a form with blank fields. Providing the value is like filling in the form for a specific mission.

There are four ways to provide values, in order of increasing precedence (later sources override earlier ones):

Method 1: Default Values (in the variable declaration)

The fallback. Used when nothing else is specified.

Method 2: terraform.tfvars file

# terraform.tfvars — Mission Apollo-Terraform: Production Values

aws_region    = "us-east-1"
mission_name  = "apollo-terraform"
environment   = "production"
instance_type = "t3.small"
crew_count    = 3

mission_config = {
  enable_monitoring = true
  backup_retention  = 30
  allowed_cidrs     = ["10.0.0.0/8", "172.16.0.0/12"]
}

Method 3: Named .tfvars files (for multiple missions)

# For a simulation mission
terraform apply -var-file="simulation.tfvars"

# For a production launch
terraform apply -var-file="production.tfvars"

# simulation.tfvars — Simulation parameters (cheaper, lower stakes)
environment   = "simulation"
instance_type = "t3.micro"
crew_count    = 1

mission_config = {
  enable_monitoring = false
  backup_retention  = 1
  allowed_cidrs     = ["0.0.0.0/0"]
}

Method 4: Environment Variables and CLI flags (for automation)

# Environment variables prefix with TF_VAR_
export TF_VAR_mission_name="apollo-terraform"
export TF_VAR_environment="production"

# Or pass directly at the command line
terraform apply -var="crew_count=5" -var="environment=staging"

📤 Outputs: The Mission Report

If Variables are the inputs to the mission, Outputs are the mission report — the telemetry sent back from space that tells you what was created, where it is, and how to reach it.

After terraform apply, you want to know: What is the IP address of my server? What is the name of the S3 bucket? What is the ARN of the IAM role?

Outputs answer these questions.

# outputs.tf — The Mission Telemetry Report

output "lunar_module_public_ip" {
  description = "Public IP address of the Lunar Module (for SSH access)"
  value       = aws_instance.lunar_module.public_ip
}

output "lunar_module_id" {
  description = "AWS instance ID of the Lunar Module"
  value       = aws_instance.lunar_module.id
}

output "launch_pad_vpc_id" {
  description = "VPC ID of the Launch Pad network"
  value       = aws_vpc.launch_pad.id
}

output "mission_summary" {
  description = "Complete mission deployment summary"
  value = {
    mission     = var.mission_name
    environment = var.environment
    region      = var.aws_region
    server_ip   = aws_instance.lunar_module.public_ip
    server_id   = aws_instance.lunar_module.id
    vpc_id      = aws_vpc.launch_pad.id
  }
}

# Sensitive outputs — marked, so Terraform won't display them in logs
output "database_password" {
  description = "The database password (sensitive — not displayed in logs)"
  value       = random_password.db_password.result
  sensitive   = true   # Redacted in terminal output; still stored in state
}

After terraform apply, you retrieve outputs:

# See all outputs
terraform output

# See one specific output
terraform output lunar_module_public_ip

# Output as JSON (for scripts and pipelines)
terraform output -json

# Example output:
# lunar_module_public_ip = "54.123.45.67"
# launch_pad_vpc_id = "vpc-0a1b2c3d4e5f"

📊 The SIPOC of Episode 3

🔄 Locals: The Derived Calculations

Between inputs and outputs, there is a third category: locals. These are computed values derived from variables and resource attributes — the mission’s internal calculations that don’t need to be exposed as parameters.

# locals.tf — Internal Mission Calculations

locals {
  # Derived naming convention — consistent across all resources
  name_prefix = "${var.mission_name}-${var.environment}"

  # Common tags — applied to everything, computed once
  common_tags = {
    Mission     = var.mission_name
    Environment = var.environment
    ManagedBy   = "terraform"
    LaunchDate  = formatdate("YYYY-MM-DD", timestamp())
  }

  # Conditional logic — which AMI for which environment?
  ami_id = var.environment == "production" ? "ami-prod-0abc123" : "ami-dev-0def456"

  # Computed CIDR blocks
  public_subnet_cidrs  = [for i in range(3) : cidrsubnet(var.vpc_cidr, 8, i)]
  private_subnet_cidrs = [for i in range(3) : cidrsubnet(var.vpc_cidr, 8, i + 10)]
}

# Use in resources:
resource "aws_instance" "lunar_module" {
  ami           = local.ami_id
  instance_type = var.instance_type
  tags          = merge(local.common_tags, { Name = "${local.name_prefix}-lunar-module" })
}

Locals are the mission engineer’s scratch pad. They transform raw parameters into usable values without exposing the intermediate calculations to the outside world.

🌟 The Blueprint Complete

We now have a Terraform configuration that:

• Accepts parameters — mission name, environment, region, instance type
• Validates those parameters before any infrastructure is created
• Computes derived values using locals
• Creates real infrastructure using the parameterised values
• Reports back the critical attributes through outputs

This same blueprint can now be used to deploy:

• A simulation mission in us-east-1 with t3.micro
• A staging mission in eu-west-1 with t3.small
• A production mission in us-east-1 with t3.large and 3 instances

One blueprint. Multiple missions. Exactly as NASA intended.

🌕 Next episode: **The Pre-Flight Checklist* — we go deep on terraform plan and learn why you should never, ever apply without planning first.*

It is the same reason you do not fire a rocket engine without checking all 400,000 components first.

The Gifts Are Under the Tree — From Spec to Merged PR 🎄

Accompanying source code repository: Santa Augmentcode Intent

Every year, on the morning of December 25th, I allow myself one quiet moment before the sleigh is unpacked and the Thank-You Letters start arriving. I sit in the empty Workshop, still warm from the night’s work, and look at the bare shelves where the gifts used to be. They are gone because they were delivered. Every one of them. On time, as specified, to the right address. That moment — that quiet confirmation that everything worked — is what we have been building towards in this entire series. Today, we deliver.

The Complete Picture

Over the past seven episodes, we have assembled all the pieces of the Intent workshop:

• Episode 1: The Workshop and what Intent is.
• Episode 2: The Living Spec — the source of truth.
• Episode 3: Santa the Coordinator and the Specialist Elves.
• Episode 4: Isolated workspaces and resumable sessions.
• Episode 5: Spec-Driven Development and finishing on time.
• Episode 6: The Context Engine — the Workshop Library.
• Episode 7: Multi-agent orchestration in waves.

Now we put them all together and walk through a complete Intent session, from the moment Head Elf Pepper opens the application to the moment the pull request is merged.

The Scenario

Goal: Add a real-time gift delivery progress dashboard to the North Pole’s internal web application. The dashboard should show live sleigh position, remaining delivery count, and an estimated completion time. It must work on tablets and update every 30 seconds.

Constraints:

• Use the existing Reindeer GPS API (v2)
• No changes to the Delivery Manifest microservice
• Safari / iPad compatible
• Must pass existing end-to-end test suite

Step 1: Open Intent and Set the Goal

Pepper opens Intent on her MacBook. She types into the Coordinator:

We need a real-time gift delivery dashboard. Show sleigh position
on a map, remaining delivery count, and estimated completion time.
Updates every 30 seconds. Must work on iPad Safari.
Use Reindeer GPS API v2. No changes to Delivery Manifest Service.

The Coordinator reads this prompt alongside the Context Engine’s analysis of the codebase. It knows the existing frontend stack (React, TypeScript), the API patterns used elsewhere in the project, and the existing test suite structure.

Step 2: The Coordinator Drafts the Living Spec

Within seconds, the Coordinator produces:

## Gift Delivery Dashboard — Living Spec

### Goal
Real-time dashboard showing sleigh position, delivery count,
and ETA. Updates every 30 seconds. iPad Safari compatible.

### Success Criteria
- [ ] Map renders in < 1s on iPad Safari
- [ ] Position updates within 30s of GPS data change
- [ ] Delivery count matches Manifest API response
- [ ] ETA calculated from current position + remaining stops
- [ ] All existing e2e tests pass
- [ ] Lighthouse accessibility score ≥ 90

### Constraints
- Reindeer GPS API v2 (existing auth token pattern)
- Delivery Manifest Service: read-only, no new endpoints
- Safari / iPad: no Chrome-only APIs

### Architecture
- New React component: `<DeliveryDashboard />`
- GPS polling service (30s interval, exponential backoff on fail)
- Map: Leaflet.js (already in dependencies — see package.json)
- Offline fallback: show last known position with staleness indicator

### Tasks
- [ ] GPS Polling Service — GPS Elf
- [ ] Map Component — Map Elf
- [ ] Delivery Count & ETA Widget — Data Elf
- [ ] Safari/iPad CSS fixes — Responsive Elf
- [ ] Integration tests — Test Elf (starts after GPS + Map done)
- [ ] Accessibility audit — A11y Elf (background)

### Decisions
(none yet)

Pepper reads the spec. She adds one clarification: “ETA should display in local Workshop time, not UTC.” The Coordinator updates the spec and records the decision.

Review time: 4 minutes. No code written yet. One important decision already captured.

Step 3: Intent Creates Isolated Workspaces

The Coordinator identifies the dependency graph:

• GPS Elf and Map Elf can start in parallel immediately.
• Data Elf can start immediately (it only reads from the Manifest API).
• Responsive Elf can start once Map Elf has a working component.
• Test Elf starts after GPS Elf and Map Elf complete.
• A11y Elf runs as a background agent throughout.

Intent creates five Git worktrees:

feat/dashboard-gps-service        ← GPS Elf
feat/dashboard-map-component      ← Map Elf
feat/dashboard-data-widgets       ← Data Elf
feat/dashboard-responsive         ← Responsive Elf (waiting)
feat/dashboard-tests              ← Test Elf (waiting)

Wave 1 agents — GPS Elf, Map Elf, Data Elf — start simultaneously. The A11y Elf begins in the background.

Step 4: Wave 1 Runs

Pepper watches the Intent window. Three agent conversations are active. Code appears in the Changes panel. The spec’s task list updates as work progresses.

GPS Elf implements the polling service, using the existing auth token pattern it found via the Context Engine:

// gps-polling.service.ts
export class GpsPollingService {
  private interval = 30_000;
  private backoff = 1;

  async startPolling(onUpdate: (pos: SleighPosition) => void) {
    const poll = async () => {
      try {
        const pos = await reindeerGpsApi.getCurrentPosition();
        onUpdate(pos);
        this.backoff = 1;
      } catch {
        this.backoff = Math.min(this.backoff * 2, 8);
      }
      setTimeout(poll, this.interval * this.backoff);
    };
    poll();
  }
}

The spec updates: ✅ GPS Polling Service — GPS Elf — done.

Map Elf creates the <DeliveryMap /> component using Leaflet.js, which it found already installed in package.json via the Context Engine. It does not install a duplicate library.

Data Elf builds the delivery count and ETA widget, correctly calling the Manifest API’s read-only endpoint and displaying ETA in Workshop local time (it read the spec decision).

Step 5: Handoffs and Wave 2

Both GPS Elf and Map Elf report completion. The spec records the interfaces they produced:

### Decisions
- GPS service exposes: `startPolling(cb: (SleighPosition) => void)`
- Map component props: `{ position: SleighPosition; zoom?: number }`

The Coordinator briefs Responsive Elf with the updated spec and the actual component structure. No guesswork. Test Elf receives both the GPS service interface and the Map component props, plus the existing e2e test patterns from the Context Engine.

Wave 2 begins. Responsive Elf adds Safari/iPad CSS. Test Elf writes integration tests.

Step 6: The Verifier Checks Everything

Wave 2 complete. The Coordinator spawns the Verifier Elf with the full spec and all five implementations.

Verifier’s report:

✅ Map renders in < 1s on iPad Safari — confirmed (Lighthouse: 0.7s)
✅ Position updates within 30s — confirmed
✅ Delivery count matches Manifest API — confirmed
✅ ETA in Workshop local time — confirmed
✅ Existing e2e tests pass — confirmed
✅ Lighthouse accessibility score ≥ 90 — confirmed (score: 94)
⚠️  Minor: GPS service does not log polling errors to existing
    structured logger (see logger.ts — used throughout codebase)

The warning is real and useful. The Context Engine told the Verifier about logger.ts. A generic agent would have missed it.

The Coordinator sends the GPS Elf back for a five-minute fix. It adds one line:

} catch (err) {
  logger.warn('GPS polling failed', { error: err, backoff: this.backoff });

Re-verification: all green.

Step 7: The Pull Request

The Coordinator integrates all five worktrees into a single branch feat/delivery-dashboard and opens a pull request. The PR description is generated from the Living Spec:

## Gift Delivery Dashboard

Implements real-time dashboard (sleigh position, delivery count, ETA).

### Changes
- New: `GpsPollingService` with 30s polling + exponential backoff
- New: `<DeliveryMap />` using existing Leaflet.js dependency
- New: `<DeliveryStats />` widget with ETA in Workshop local time
- New: iPad/Safari responsive CSS
- New: Integration test suite (12 tests, all passing)

### Verified Against Spec
All 6 success criteria confirmed by Verifier Agent.
Existing e2e suite: all passing.

### Decisions Recorded
- ETA displayed in Workshop local time (not UTC) — per Pepper, Dec 3
- Used existing Leaflet.js (not installed new mapping library)
- GPS errors logged via existing structured logger (logger.ts)

Pepper reviews the spec (4 minutes). She reviews the diff (10 minutes, because the spec told her exactly what to look for). She approves.

Total elapsed time: 47 minutes. Zero rework. Christmas safe.

What We Built Together

Over this series, Father Christmas and Head Elf Pepper have explained every layer of Intent:

SIPOC: The Complete Intent Workflow

Getting Started

Intent is available in public beta for macOS. Download it here. It uses your existing Augment credits. You can also bring Claude Code, Codex, or OpenCode if you already have subscriptions.

Augment’s documentation is at docs.augmentcode.com. Their manifesto — The End of Linear Work — is worth reading before your first session.

A Final Word from Father Christmas

I have been doing this for over a thousand years. Every century, the tools improve. The quill gave way to the telegraph, the telegraph to the computer, and now the computer gives way to the agent. But the fundamental challenge has never changed: how do you coordinate complex, parallel work towards a shared goal, on an unmovable deadline, without chaos?The answer, in 1025 and in 2025, is the same: a clear plan, a good team, and the discipline to keep the plan honest.Augment Intent is the first software I have encountered that truly understands this. It puts the plan first. It keeps the plan honest. It coordinates the team without the Elves colliding. And it finishes on time.I am proud of everything we have built in this Workshop. I hope you will build something wonderful in yours.Merry Christmas, and Happy Coding.Ho ho ho! 🎅

This concludes the Santa Augmentcode Intent series. All eight episodes are available on dev.to under the the-software-s-journey organisation.

Thank you for reading. May your specs be living and your merges be clean.