Examples — Real Plans, Real Code

Phase 12: User Profile & Dashboard

🟡 HARDENED 3 days · 12 slices Risk: Medium

Add user profile management and personalized dashboard. Users can view/edit their profile, see activity history, and access personalized metrics with full multi-tenant isolation.

Acceptance Criteria

☐ Users can view and edit their profile (name, email, avatar)
☐ Dashboard shows personalized metrics (last login, activity count)
☐ Profile changes are audited in the activity log
☐ Multi-tenant isolation — users only see their own tenant's data
☐ 90%+ test coverage on new code

Slice 12.1 — Database Migration: `user_profiles` Table

Tasks

1. Create migration V012__add_user_profiles.sql

2. Add columns: display_name, avatar_url, bio, last_login_at

3. Add RLS policy: WHERE tenant_id = current_setting('app.tenant_id')

4. Write integration test: verify RLS blocks cross-tenant access

Validation Gate

dotnet build                                        # zero errors
dotnet test --filter "Category=Integration"         # all pass
grep -rn "string interpolation" --include="*.cs"    # zero hits in new files

Stop Condition: If RLS policy fails integration test → STOP, do not proceed.

Slice 12.2 — Repository Layer: `UserProfileRepository`

Tasks

1. Create IUserProfileRepository interface

2. Implement with Dapper, parameterized queries

3. Methods: GetByUserIdAsync, UpdateAsync, GetActivitySummaryAsync

4. Unit tests for all repository methods

View full .NET example on GitHub →

Phase 8: Real-Time Notifications

🟡 HARDENED 2 days · 8 slices Risk: Medium

Add real-time notification system using Socket.io. Users receive live updates for order status changes, new messages, and system alerts. Notifications persisted in PostgreSQL.

Acceptance Criteria

☐ Notifications delivered in real-time via WebSocket
☐ Notifications persisted with read/unread status
☐ API endpoints: list, mark-read, mark-all-read
☐ React notification bell component with unread count badge
☐ Multi-tenant isolation — users only see their own notifications

Slice 8.1 — Database: Notifications Table

Prisma Schema

model Notification {
  id        String    @id @default(uuid())
  userId    String    @map("user_id")
  tenantId  String    @map("tenant_id")
  type      String    // "order_update" | "message" | "system"
  title     String
  body      String
  readAt    DateTime? @map("read_at")
  createdAt DateTime  @default(now()) @map("created_at")

  @@index([tenantId, userId, readAt])
  @@map("notifications")
}

View full TypeScript example on GitHub →

Phase 5: Background Task Queue

🟡 HARDENED 2 days · 6 slices Risk: Low-Medium

Add a background task queue for async processing: email sending, report generation, and data import jobs. Uses Celery with Redis as the broker and PostgreSQL for result storage.

Acceptance Criteria

☐ Celery worker processes tasks from Redis queue
☐ Three task types: email, report generation, data import
☐ Task status tracking (pending, running, completed, failed)
☐ Retry logic with exponential backoff
☐ 90%+ test coverage on new code

Slice 5.1 — Database: `tasks` Table + Alembic Migration

SQLAlchemy Model

class Task(Base):
    __tablename__ = "tasks"

    id: Mapped[str] = mapped_column(String, primary_key=True)
    tenant_id: Mapped[str] = mapped_column(String, nullable=False, index=True)
    type: Mapped[str] = mapped_column(String(50), nullable=False)
    status: Mapped[str] = mapped_column(String(20), default="pending")
    payload: Mapped[dict] = mapped_column(JSONB, nullable=False)
    result: Mapped[dict | None] = mapped_column(JSONB, nullable=True)
    created_at: Mapped[datetime] = mapped_column(DateTime, server_default=func.now())

Validation Gate

mypy .                                              # zero errors
pytest --tb=short                                   # all pass
grep -rn "type: ignore\|Any" --include="*.py" app/  # minimal in new files

Stop Condition: If migration fails or tenant isolation test fails → STOP.

View full Python example on GitHub →

Phase 8: Order Processing API

🟡 HARDENED 3 days · 10 slices Risk: Medium

Build a RESTful order processing API with Spring Boot. Idempotent order creation, stock validation, event publishing, and full multi-tenant isolation.

Acceptance Criteria

☐ Customers can create orders (idempotent via idempotency key)
☐ Orders validate product availability before committing
☐ Status transitions: PENDING → CONFIRMED → SHIPPED → DELIVERED
☐ Order history endpoint with pagination
☐ Multi-tenant isolation — customers only see their own tenant's orders

Slice 8.1 — Database: Flyway Migration for Orders

SQL Migration

CREATE TABLE orders (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id       VARCHAR(50)  NOT NULL,
    customer_id     UUID         NOT NULL,
    status          VARCHAR(20)  NOT NULL DEFAULT 'PENDING',
    total           DECIMAL(12,2) NOT NULL,
    idempotency_key VARCHAR(255),
    created_at      TIMESTAMP    NOT NULL DEFAULT now(),
    CONSTRAINT uq_order_idempotency UNIQUE (tenant_id, idempotency_key)
);

CREATE INDEX idx_orders_tenant_customer ON orders(tenant_id, customer_id);

Validation Gate

./gradlew build                                          # zero errors
./gradlew test --tests "*IntegrationTest*"               # all pass
grep -rn "DriverManager\|getConnection(" --include="*.java" src/  # zero hits

Stop Condition: If migration fails or tenant isolation test fails → STOP, do not proceed.

View full Java example on GitHub →

Phase 6: REST API & Middleware

🟡 HARDENED 2 days · 8 slices Risk: Medium

Build a RESTful API for user management with Chi router, middleware chain (logging, auth, rate limiting), PostgreSQL persistence via pgx, and structured JSON error responses.

Acceptance Criteria

☐ CRUD endpoints for users (GET, POST, PUT, DELETE)
☐ JWT authentication middleware
☐ Rate limiting middleware (token bucket)
☐ Structured error responses (JSON, consistent format)
☐ Multi-tenant isolation via tenant_id in all queries
☐ go test -race ./... passes with zero races

Slice 6.1 — Database: Migration for `users` Table

SQL Migration

CREATE TABLE users (
    id         UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id  VARCHAR(50)  NOT NULL,
    name       VARCHAR(255) NOT NULL,
    email      VARCHAR(255) NOT NULL,
    created_at TIMESTAMP    NOT NULL DEFAULT now(),
    updated_at TIMESTAMP    NOT NULL DEFAULT now(),
    CONSTRAINT uq_users_tenant_email UNIQUE (tenant_id, email)
);

CREATE INDEX idx_users_tenant ON users(tenant_id);

Validation Gate

go build ./...                                           # zero errors
go vet ./...                                             # zero warnings
go test -short ./...                                     # all pass
grep -rn 'fmt.Sprintf.*SELECT' --include="*.go"          # zero hits

Stop Condition: If migration fails or tenant isolation test fails → STOP.

View full Go example on GitHub →

Real Plans. Real Code.

Phase 12: User Profile & Dashboard

Acceptance Criteria

Slice 12.1 — Database Migration: `user_profiles` Table

Slice 12.2 — Repository Layer: `UserProfileRepository`

Phase 8: Real-Time Notifications

Acceptance Criteria

Slice 8.1 — Database: Notifications Table

Phase 5: Background Task Queue

Acceptance Criteria

Slice 5.1 — Database: `tasks` Table + Alembic Migration

Phase 8: Order Processing API

Acceptance Criteria

Slice 8.1 — Database: Flyway Migration for Orders

Phase 6: REST API & Middleware

Acceptance Criteria

Slice 6.1 — Database: Migration for `users` Table

Azure IaC — Bicep / Terraform / azd

What the Preset Installs

12 Instruction Files

5 Specialized Agents

Azure Sweeper — 8-Layer Enterprise Governance Audit

Project-Level Examples

Project Principles Example

Project Profile Example

Real Plans. Real Code.

Phase 12: User Profile & Dashboard

Acceptance Criteria

Slice 12.1 — Database Migration: user_profiles Table

Slice 12.2 — Repository Layer: UserProfileRepository

Phase 8: Real-Time Notifications

Acceptance Criteria

Slice 8.1 — Database: Notifications Table

Phase 5: Background Task Queue

Acceptance Criteria

Slice 5.1 — Database: tasks Table + Alembic Migration

Phase 8: Order Processing API

Acceptance Criteria

Slice 8.1 — Database: Flyway Migration for Orders

Phase 6: REST API & Middleware

Acceptance Criteria

Slice 6.1 — Database: Migration for users Table

Azure IaC — Bicep / Terraform / azd

What the Preset Installs

12 Instruction Files

5 Specialized Agents

Azure Sweeper — 8-Layer Enterprise Governance Audit

Project-Level Examples

Project Principles Example

Project Profile Example

Slice 12.1 — Database Migration: `user_profiles` Table

Slice 12.2 — Repository Layer: `UserProfileRepository`

Slice 5.1 — Database: `tasks` Table + Alembic Migration

Slice 6.1 — Database: Migration for `users` Table