Project 6: Trunk-Based Development Pipeline — Implement Feature Flags and CI

A complete trunk-based development pipeline with feature flags, automated testing on every commit, and a CLI tool that manages short-lived branches and enforces trunk-based discipline.

Quick Reference

Attribute	Value
Difficulty	Advanced
Time Estimate	2-3 weeks
Main Programming Language	Python
Alternative Programming Languages	Go, Bash, TypeScript
Coolness Level	Level 3: Genuinely Clever
Business Potential	3. The “Service & Support” Model
Prerequisites	Projects 1-5 completed, understanding of CI systems
Key Topics	Trunk-Based Development, Feature Flags, Continuous Integration

1. Learning Objectives

By completing this project, you will:

Implement a working version of: A complete trunk-based development pipeline with feature flags, automated testing on every commit, and a CLI tool that manages short-lived branches and enforces trunk-based discipline..
Explain the core Git workflow tradeoff this project is designed to surface.
Design deterministic checks so results can be verified and reproduced.
Document operational failure modes and safe recovery actions.

2. All Theory Needed (Per-Concept Breakdown)

Trunk-Based Development

Fundamentals This concept matters in this project because your implementation will fail or become non-deterministic without a precise model of Trunk-Based Development. You should define what the concept controls, what invariants must hold, and which actions are safe versus destructive. Treat this concept as a production concern, not a tutorial checkbox.

Deep Dive into the concept When applying Trunk-Based Development in this project, reason in three passes: data shape, state transitions, and enforcement. First, identify which artifacts are authoritative (commit objects, refs, metadata, policy config, CI status, or scan findings). Second, map how those artifacts change when your tool runs. Third, define failure behavior explicitly. In Git tooling, silent partial success is dangerous: you need either complete success with evidence or an explicit failure state with remediation guidance. Also account for scale behavior. A workflow that works on a toy repo may fail on large history depth, concurrent updates, or mixed branch policies. Include trace logs for every irreversible action, and separate simulation mode from write mode. For interview readiness, be able to explain how this concept protects delivery speed while reducing operational risk.

How this fit on projects In this project, Trunk-Based Development is directly used in design decisions, implementation constraints, and verification criteria.

Definitions & key terms

Trunk-Based Development invariant: A condition that must remain true before and after every operation.
Safety boundary: The point where actions become destructive unless guarded.
Verification signal: Evidence proving the action behaved as expected.

Mental model diagram

Input state -> Validate invariant -> Apply change -> Verify output -> Record evidence

How it works

Capture current state and constraints.
Evaluate whether Trunk-Based Development preconditions are satisfied.
Execute the minimal safe transition.
Verify postconditions and publish an auditable result.

Failure modes: stale state, partial writes, race conditions, ambiguous output contracts.

Minimal concrete example

Plan -> dry-run -> execute -> verify -> rollback/forward-fix decision

Common misconceptions

Assuming local success implies team-safe behavior.
Treating policy violations as warnings instead of merge blockers.
Skipping deterministic verification because the output appears correct.

Check-your-understanding questions

Which invariant is most likely to break first under concurrency?
What output proves your tool handled an edge case correctly?
Where should enforcement happen: local hook, CI, or protected branch gate?

Check-your-understanding answers

The invariant tied to mutable refs or policy-dependent merge eligibility.
A deterministic transcript showing both success and controlled failure behavior.
Layered enforcement: fast local checks plus non-bypassable server-side gates.

Real-world applications

Change-management tooling for fast-moving teams.
Incident-safe release workflows with traceable rollback paths.
Compliance-ready source-control automation.

Where you’ll apply it This project and its immediate adjacent projects in this sprint.

References

https://git-scm.com/docs
https://dora.dev/capabilities/trunk-based-development/

Key insights Trunk-Based Development is only valuable when its invariants are encoded into tooling and checks.

Summary Mastering Trunk-Based Development here gives you transferable patterns for larger workflow systems.

Homework/Exercises to practice the concept

Write one failing scenario and expected detection output.
Define one invariant and one explicit violation test.

Solutions to the homework/exercises

Use a stale branch or invalid metadata case and assert deterministic error reporting.
Invariant: protected branch must not accept unchecked changes; violation test: bypass attempt should fail fast.

Feature Flags

Fundamentals This concept matters in this project because your implementation will fail or become non-deterministic without a precise model of Feature Flags. You should define what the concept controls, what invariants must hold, and which actions are safe versus destructive. Treat this concept as a production concern, not a tutorial checkbox.

Deep Dive into the concept When applying Feature Flags in this project, reason in three passes: data shape, state transitions, and enforcement. First, identify which artifacts are authoritative (commit objects, refs, metadata, policy config, CI status, or scan findings). Second, map how those artifacts change when your tool runs. Third, define failure behavior explicitly. In Git tooling, silent partial success is dangerous: you need either complete success with evidence or an explicit failure state with remediation guidance. Also account for scale behavior. A workflow that works on a toy repo may fail on large history depth, concurrent updates, or mixed branch policies. Include trace logs for every irreversible action, and separate simulation mode from write mode. For interview readiness, be able to explain how this concept protects delivery speed while reducing operational risk.

How this fit on projects In this project, Feature Flags is directly used in design decisions, implementation constraints, and verification criteria.

Definitions & key terms

Feature Flags invariant: A condition that must remain true before and after every operation.
Safety boundary: The point where actions become destructive unless guarded.
Verification signal: Evidence proving the action behaved as expected.

Mental model diagram

Input state -> Validate invariant -> Apply change -> Verify output -> Record evidence

How it works

Capture current state and constraints.
Evaluate whether Feature Flags preconditions are satisfied.
Execute the minimal safe transition.
Verify postconditions and publish an auditable result.

Failure modes: stale state, partial writes, race conditions, ambiguous output contracts.

Minimal concrete example

Plan -> dry-run -> execute -> verify -> rollback/forward-fix decision

Common misconceptions

Assuming local success implies team-safe behavior.
Treating policy violations as warnings instead of merge blockers.
Skipping deterministic verification because the output appears correct.

Check-your-understanding questions

Which invariant is most likely to break first under concurrency?
What output proves your tool handled an edge case correctly?
Where should enforcement happen: local hook, CI, or protected branch gate?

Check-your-understanding answers

The invariant tied to mutable refs or policy-dependent merge eligibility.
A deterministic transcript showing both success and controlled failure behavior.
Layered enforcement: fast local checks plus non-bypassable server-side gates.

Real-world applications

Change-management tooling for fast-moving teams.
Incident-safe release workflows with traceable rollback paths.
Compliance-ready source-control automation.

Where you’ll apply it This project and its immediate adjacent projects in this sprint.

References

https://git-scm.com/docs
https://dora.dev/capabilities/trunk-based-development/

Key insights Feature Flags is only valuable when its invariants are encoded into tooling and checks.

Summary Mastering Feature Flags here gives you transferable patterns for larger workflow systems.

Homework/Exercises to practice the concept

Write one failing scenario and expected detection output.
Define one invariant and one explicit violation test.

Solutions to the homework/exercises

Use a stale branch or invalid metadata case and assert deterministic error reporting.
Invariant: protected branch must not accept unchecked changes; violation test: bypass attempt should fail fast.

Continuous Integration

Fundamentals This concept matters in this project because your implementation will fail or become non-deterministic without a precise model of Continuous Integration. You should define what the concept controls, what invariants must hold, and which actions are safe versus destructive. Treat this concept as a production concern, not a tutorial checkbox.

Deep Dive into the concept When applying Continuous Integration in this project, reason in three passes: data shape, state transitions, and enforcement. First, identify which artifacts are authoritative (commit objects, refs, metadata, policy config, CI status, or scan findings). Second, map how those artifacts change when your tool runs. Third, define failure behavior explicitly. In Git tooling, silent partial success is dangerous: you need either complete success with evidence or an explicit failure state with remediation guidance. Also account for scale behavior. A workflow that works on a toy repo may fail on large history depth, concurrent updates, or mixed branch policies. Include trace logs for every irreversible action, and separate simulation mode from write mode. For interview readiness, be able to explain how this concept protects delivery speed while reducing operational risk.

How this fit on projects In this project, Continuous Integration is directly used in design decisions, implementation constraints, and verification criteria.

Definitions & key terms

Continuous Integration invariant: A condition that must remain true before and after every operation.
Safety boundary: The point where actions become destructive unless guarded.
Verification signal: Evidence proving the action behaved as expected.

Mental model diagram

Input state -> Validate invariant -> Apply change -> Verify output -> Record evidence

How it works

Capture current state and constraints.
Evaluate whether Continuous Integration preconditions are satisfied.
Execute the minimal safe transition.
Verify postconditions and publish an auditable result.

Failure modes: stale state, partial writes, race conditions, ambiguous output contracts.

Minimal concrete example

Plan -> dry-run -> execute -> verify -> rollback/forward-fix decision

Common misconceptions

Assuming local success implies team-safe behavior.
Treating policy violations as warnings instead of merge blockers.
Skipping deterministic verification because the output appears correct.

Check-your-understanding questions

Which invariant is most likely to break first under concurrency?
What output proves your tool handled an edge case correctly?
Where should enforcement happen: local hook, CI, or protected branch gate?

Check-your-understanding answers

The invariant tied to mutable refs or policy-dependent merge eligibility.
A deterministic transcript showing both success and controlled failure behavior.
Layered enforcement: fast local checks plus non-bypassable server-side gates.

Real-world applications

Change-management tooling for fast-moving teams.
Incident-safe release workflows with traceable rollback paths.
Compliance-ready source-control automation.

Where you’ll apply it This project and its immediate adjacent projects in this sprint.

References

https://git-scm.com/docs
https://dora.dev/capabilities/trunk-based-development/

Key insights Continuous Integration is only valuable when its invariants are encoded into tooling and checks.

Summary Mastering Continuous Integration here gives you transferable patterns for larger workflow systems.

Homework/Exercises to practice the concept

Write one failing scenario and expected detection output.
Define one invariant and one explicit violation test.

Solutions to the homework/exercises

Use a stale branch or invalid metadata case and assert deterministic error reporting.
Invariant: protected branch must not accept unchecked changes; violation test: bypass attempt should fail fast.

3. Project Specification

3.1 What You Will Build

A complete trunk-based development pipeline with feature flags, automated testing on every commit, and a CLI tool that manages short-lived branches and enforces trunk-based discipline.

3.2 Functional Requirements

Scope control: Deliver a deterministic and testable implementation.
Correctness: Preserve Git invariants and policy constraints.

3.3 Non-Functional Requirements

Performance: Deterministic execution with documented runtime behavior on representative history sizes.
Reliability: Repeated runs on the same input produce identical outputs.
Usability: Clear CLI or report output for both success and failure cases.

3.4 Example Usage / Output

You’ll have a CLI and supporting infrastructure for trunk-based development:

Example Output:

$ trunk init
Initializing trunk-based development for this repository...
✓ Created .trunk/config.yaml
✓ Created .trunk/feature-flags.json
✓ Set up branch policies in .github/settings.yaml
✓ Created GitHub Actions workflow

Trunk-based development enabled!
Main branch: main
Max branch age: 2 days
Feature flags file: .trunk/feature-flags.json

$ trunk branch create auth-improvements
Creating short-lived branch 'auth-improvements'...
✓ Branch created from main
✓ Tracking enabled (will warn if branch > 2 days)
✓ Upstream set to origin/main

Tip: Merge back to main within 2 days to stay trunk-based!

$ trunk status
=== Trunk Status ===

Main branch: main (12 commits ahead of last deploy)

Active branches:
  auth-improvements  (you)   0.5 days old  ✓ fresh
  user-profile       (alice)  1.8 days old  ⚠️ getting stale
  legacy-cleanup     (bob)    4.2 days old  ❌ STALE - violates trunk-based

Feature flags:
  new_auth_flow:    enabled for: internal, beta-users
  profile_v2:       disabled (in development)
  dark_mode:        enabled for: 10% rollout

$ trunk flag create new-checkout-flow
Created feature flag 'new_checkout_flow' (disabled by default)

Updated .trunk/feature-flags.json:
{
  "new_checkout_flow": {
    "enabled": false,
    "enabledFor": [],
    "createdAt": "2024-01-15",
    "owner": "you"
  }
}

Usage in code:
  if (isEnabled('new_checkout_flow')) {
    // new code
  }

$ trunk merge
Running pre-merge checks...
✓ Branch age: 0.5 days (ok)
✓ Tests passed
✓ No merge conflicts with main
✓ Code review approved

Squash-merging 3 commits into main...
[main abc1234] feat: improve auth flow (#127)

✓ Branch 'auth-improvements' merged and deleted
✓ Deployment triggered to staging

3.5 Data Formats / Schemas / Protocols

Describe input repository assumptions, output report shape, and any policy/config schema consumed by the tool.

3.6 Edge Cases

Empty repository or shallow clone state.
Detached HEAD or rewritten history during execution.
Invalid metadata/policy configuration.

3.7 Real World Outcome

You’ll have a CLI and supporting infrastructure for trunk-based development:

Example Output:

$ trunk init
Initializing trunk-based development for this repository...
✓ Created .trunk/config.yaml
✓ Created .trunk/feature-flags.json
✓ Set up branch policies in .github/settings.yaml
✓ Created GitHub Actions workflow

Trunk-based development enabled!
Main branch: main
Max branch age: 2 days
Feature flags file: .trunk/feature-flags.json

$ trunk branch create auth-improvements
Creating short-lived branch 'auth-improvements'...
✓ Branch created from main
✓ Tracking enabled (will warn if branch > 2 days)
✓ Upstream set to origin/main

Tip: Merge back to main within 2 days to stay trunk-based!

$ trunk status
=== Trunk Status ===

Main branch: main (12 commits ahead of last deploy)

Active branches:
  auth-improvements  (you)   0.5 days old  ✓ fresh
  user-profile       (alice)  1.8 days old  ⚠️ getting stale
  legacy-cleanup     (bob)    4.2 days old  ❌ STALE - violates trunk-based

Feature flags:
  new_auth_flow:    enabled for: internal, beta-users
  profile_v2:       disabled (in development)
  dark_mode:        enabled for: 10% rollout

$ trunk flag create new-checkout-flow
Created feature flag 'new_checkout_flow' (disabled by default)

Updated .trunk/feature-flags.json:
{
  "new_checkout_flow": {
    "enabled": false,
    "enabledFor": [],
    "createdAt": "2024-01-15",
    "owner": "you"
  }
}

Usage in code:
  if (isEnabled('new_checkout_flow')) {
    // new code
  }

$ trunk merge
Running pre-merge checks...
✓ Branch age: 0.5 days (ok)
✓ Tests passed
✓ No merge conflicts with main
✓ Code review approved

Squash-merging 3 commits into main...
[main abc1234] feat: improve auth flow (#127)

✓ Branch 'auth-improvements' merged and deleted
✓ Deployment triggered to staging

4. Solution Architecture

4.1 High-Level Design

Inputs -> Validation -> Core Engine -> Output Formatter -> Verification Report

4.2 Key Components

Component	Responsibility	Key Decisions
Input loader	Discover commits/refs/config inputs	Deterministic ordering and clear failure messages
Core engine	Compute project-specific logic	Separate read-only simulation from mutating actions
Reporter	Produce user-facing output and evidence	Include machine-readable and human-readable forms

4.4 Data Structures (No Full Code)

ProjectState { refs, commits, policy, findings, metrics }
Result { status, evidence, warnings, next_actions }

4.4 Algorithm Overview

Collect state from repository and configuration.
Evaluate invariants and policy preconditions.
Execute core transformation or analysis logic.
Verify postconditions and emit deterministic report.

Complexity Analysis:

Time: O(history + affected scope)
Space: O(active graph window + report size)

5. Implementation Guide

5.1 Development Environment Setup

Use the environment defined in the main guide. Pin tool versions and fixture data to keep outputs reproducible.

5.2 Project Structure

project-root/
├── fixtures/
├── src/
├── tests/
├── docs/
└── README.md

5.3 The Core Question You’re Answering

“Why do high-performing teams commit directly to main, and how do they ship incomplete features without breaking production?”

Before you write any code, sit with this question. The answer is feature flags plus CI/CD. Incomplete code goes to production but is hidden behind flags. This eliminates merge hell and enables true continuous integration.

5.4 Concepts You Must Understand First

Stop and research these before coding:

Trunk-Based Development
- What defines trunk-based development vs. GitFlow?
- Why are short-lived branches (< 2 days) important?
- How do you handle work that takes longer than 2 days?
- Book Reference: “Accelerate” Ch. 4 — Forsgren
Feature Flags
- What’s the difference between release flags and experiment flags?
- How do you gradually roll out a feature (canary deployment)?
- What’s the lifecycle of a feature flag?
- Book Reference: “Continuous Delivery” Ch. 10 — Humble & Farley
Continuous Integration
- What’s the difference between CI and continuous delivery?
- Why must you build on every commit in trunk-based?
- How do you handle flaky tests?
- Book Reference: “The DevOps Handbook” Ch. 3 — Kim et al.

5.5 Questions to Guide Your Design

Before implementing, think through these:

Branch Policies
- How will you track branch age?
- What should happen when a branch exceeds the limit?
- How do you handle exceptions (releases, hotfixes)?
Feature Flags
- Where should flags be stored (code, config, external service)?
- How do you handle flag evaluation at runtime?
- How do you clean up old flags?
CI Integration
- What workflows need to run on each commit?
- How do you handle test failures on main?
- How do you integrate with existing CI systems?

5.6 Thinking Exercise

Simulate a Trunk-Based Sprint

Plan how you’d implement a feature trunk-based:

Feature: Add password strength indicator to signup

Day 1: Create branch, add strength calculation logic (behind flag)
       Commit to main (hidden behind flag, passes tests)

Day 2: Add UI component (behind flag), deploy to staging
       Internal QA tests with flag enabled

Day 3: Enable for beta users, collect feedback

Day 4: Fix issues based on feedback, new commits to main

Day 5: Enable for 25% of users

Week 2: 100% rollout, remove feature flag, delete old code

Questions while planning:

Where are the merge conflicts? (Answer: nowhere!)
What if you find a bug during rollout?
What if the feature needs to be reverted?
How long was the branch alive? (1-2 days per micro-feature)

5.7 The Interview Questions They’ll Ask

Prepare to answer these:

“Explain trunk-based development and why it reduces integration problems.”
“How would you implement a feature flag system from scratch?”
“What’s the difference between a feature flag and a configuration setting?”
“How do you handle database migrations in trunk-based development?”
“What testing strategies are essential for trunk-based development?”

5.8 Hints in Layers

Hint 1: Starting Point Start with the branch age tracker. Use git log -1 --format=%ct to get the creation timestamp. Store branch metadata in .trunk/.

Hint 2: Feature Flags A simple JSON file works for small teams. For runtime, load the JSON and expose an isEnabled(flagName, context) function.

Hint 3: CI Integration Generate a GitHub Actions workflow that runs on push to main. Use the on: push trigger with proper caching for speed.

Hint 4: Merge Tooling Your trunk merge should: check age, run tests locally, squash commits, push, and delete the remote branch.

5.9 Books That Will Help

Topic	Book	Chapter
Trunk-based development	“Accelerate” by Forsgren	Ch. 4
Feature flags	“Continuous Delivery” by Humble & Farley	Ch. 10
DevOps practices	“The DevOps Handbook” by Kim et al.	Ch. 3-5

5.10 Implementation Phases

Phase 1: Foundation (1-2 sessions)

Define fixtures, expected outputs, and invariant checks.
Build read-only analysis path.

Phase 2: Core Functionality (2-4 sessions)

Implement project-specific core logic and deterministic reporting.
Add policy and edge-case handling.

Phase 3: Polish and Edge Cases (1-2 sessions)

Add failure demos, performance notes, and usability improvements.
Finalize docs and validation transcripts.

5.11 Key Implementation Decisions

Decision	Options	Recommendation	Rationale
Execution mode	direct write vs dry-run+write	dry-run+write	Safer and easier to debug
Output contract	free text vs structured+text	structured+text	Better automation and readability
Enforcement location	local only vs local+CI	local+CI	Prevents bypass in shared branches

6. Testing Strategy

6.1 Test Categories

Unit tests for parsing and policy logic.
Integration tests on fixture repositories.
Edge-case tests for stale refs, malformed metadata, and large histories.

6.2 Critical Test Cases

Deterministic golden-path scenario.
Policy violation hard-fail scenario.
Recovery path after partial or conflicting state.

6.3 Test Data

Use fixed repository fixtures with known commit graphs and expected outputs stored under version control.

7. Common Pitfalls & Debugging

Problem 1: “Output looks correct but history or metadata is inconsistent”

Why: Validation happens after mutation, not before.
Fix: Add a preflight invariant check and a post-write verification step.
Quick test: Run the same command twice on the same fixture and verify identical results.

Problem 2: “Tool works on small repo but times out on larger history”

Why: Full traversal is performed where selective traversal is possible.
Fix: Cache intermediate graph lookups and scope analysis to affected commits/paths.
Quick test: Compare runtime on small and large fixtures with a clear budget target.

Problem 3: “Policy check can be bypassed by local-only behavior”

Why: Enforcement is advisory, not server-authoritative.
Fix: Mirror critical checks in CI and protected branch rules.
Quick test: Attempt merge with failing policy in CI and confirm hard block.

8. Extensions & Challenges

8.1 Beginner Extensions

Add richer error messages with remediation hints.
Add fixture generation helpers for repeatable demos.

8.2 Intermediate Extensions

Add performance instrumentation and budget assertions.
Add policy configuration profiles by repository type.

8.3 Advanced Extensions

Add distributed execution support for large repositories.
Add signed evidence exports for compliance workflows.

9. Real-World Connections

9.1 Industry Applications

Internal developer portals.
Enterprise repository governance systems.
Release safety and incident diagnostics tooling.

Git core: https://git-scm.com/
GitHub CLI: https://github.com/cli/cli
pre-commit framework: https://pre-commit.com/

9.3 Interview Relevance

This project prepares you for architecture and debugging interviews that focus on merge policy, CI gates, and workflow reliability tradeoffs.

10. Resources

10.1 Essential Reading

Pro Git (Internals and Workflows chapters)
Software Engineering at Google (Version control and build chapters)
Accelerate (delivery performance practices)

10.2 Video Resources

Git internals talks from Git Merge conference archives.
DORA and delivery metrics conference sessions.

10.3 Tools and Documentation

https://git-scm.com/docs
https://docs.github.com/
https://dora.dev/

Previous: 5: “Git Hooks Framework — Build Your Own Husky
Next: 7: “Code Review Bot — Automate PR Quality Checks

11. Self-Assessment Checklist

11.1 Understanding

I can explain the primary invariant this project enforces.
I can explain one failure mode and one safe recovery path.

11.2 Implementation

Functional requirements are met on deterministic fixtures.
Critical edge cases are tested and documented.

11.3 Growth

I can describe tradeoffs in an interview setting.
I documented what I would change in a production version.

12. Submission / Completion Criteria

Minimum Viable Completion:

Deterministic golden-path output exists.
One failure scenario is handled with clear output.
Core workflow objective is demonstrably met.

Full Completion:

Minimum criteria plus policy validation, structured reporting, and edge-case coverage.

Excellence:

Full completion plus measurable performance budget and production-hardening notes.

Project 6: Trunk-Based Development Pipeline — Implement Feature Flags and CI

Quick Reference

1. Learning Objectives

2. All Theory Needed (Per-Concept Breakdown)

Trunk-Based Development

Feature Flags

Continuous Integration

3. Project Specification

3.1 What You Will Build

3.2 Functional Requirements

3.3 Non-Functional Requirements

3.4 Example Usage / Output

3.5 Data Formats / Schemas / Protocols

3.6 Edge Cases

3.7 Real World Outcome

4. Solution Architecture

4.1 High-Level Design

4.2 Key Components

4.4 Data Structures (No Full Code)

4.4 Algorithm Overview

5. Implementation Guide

5.1 Development Environment Setup

5.2 Project Structure

5.3 The Core Question You’re Answering

5.4 Concepts You Must Understand First

5.5 Questions to Guide Your Design

5.6 Thinking Exercise

Simulate a Trunk-Based Sprint

5.7 The Interview Questions They’ll Ask

5.8 Hints in Layers

5.9 Books That Will Help

5.10 Implementation Phases

Phase 1: Foundation (1-2 sessions)

Phase 2: Core Functionality (2-4 sessions)

Phase 3: Polish and Edge Cases (1-2 sessions)

5.11 Key Implementation Decisions

6. Testing Strategy

6.1 Test Categories

6.2 Critical Test Cases

6.3 Test Data

7. Common Pitfalls & Debugging

8. Extensions & Challenges

8.1 Beginner Extensions

8.2 Intermediate Extensions

8.3 Advanced Extensions

9. Real-World Connections

9.1 Industry Applications

9.2 Related Open Source Projects

9.3 Interview Relevance

10. Resources

10.1 Essential Reading

10.2 Video Resources

10.3 Tools and Documentation

10.4 Related Projects in This Series

11. Self-Assessment Checklist

11.1 Understanding

11.2 Implementation

11.3 Growth

12. Submission / Completion Criteria