Samples

The samples/ directory lets you try every tiv command without touching real infrastructure. The fixtures tell one story: Brew & Bean, a coffee shop whose app grows one feature at a time. Every identifier is fictional (AWS account 123456789012), and only official HashiCorp provider resources appear.

Each size contains a state.json (the current infrastructure) and a plan.json (a set of pending changes).

Every size also ships a raw terraform.tfstate mirroring the same resources so you can compare tiv’s two state input paths side by side.

Try them

tiv plan --plan samples/Short/plan.json
tiv state --state samples/Venti/state.json
tiv state --state samples/Grande/terraform.tfstate
tiv summary --state samples/Tall/state.json --plan-file samples/Tall/plan.json
tiv plan --plan samples/Trenta/plan.json --console

The sizes

Size	The story	Worth looking at
Short	The corner shop gets a website	A small, readable report: an S3 site, DNS, a preorders table. The plan swaps a DNS record type, which forces a replacement.
Tall	Online ordering launches	~19 resources including data sources: API Gateway, Lambda, IAM. The plan shows every change type at once, including a data source re-read waiting on a pending change.
Grande	The chain expands and refactors into modules	Three modules (storefront, ordering, notifications). A queue rename ripples into its event target and alarm, all visible in the graph.
Venti	The platform play	Four modules wired together via module outputs. The plan’s queue replacement cascades across module boundaries, and the state graph shows cross-module dependency arrows.
Trenta	The franchise	Venti plus the shapes real projects have: for_each and count instances, a module nested inside another, a second provider inside a module, a resource that drifted outside Terraform, a moved resource, and the attribute that forced a replacement.

What each demonstrates

• Replace cascades: changing one resource forces updates in everything referencing it. Watch the graph in Grande and Venti plans.
• Sensitive values: masked attribute values and a masked output appear across every size.
• Raw state input: each size ships a terraform.tfstate alongside its canonical state.json, both carrying the same resources. Loading the raw file exercises tiv’s sensitive_attributes -> sensitive_values transform: every size masks at least one attribute (aws_ssm_parameter.menu_version.value in Short and Tall, module.ordering.aws_ssm_parameter.stripe_api_key.value in Grande and Venti) via the raw path rather than the canonical one.
• Unknown values: attributes showing (known after apply) appear in every plan.
• Dependency chips: open any card in the Venti state report and follow “used by” across modules.
• Module grouping: Grande, Venti and Trenta show module containers in the graph and module grouping in the lists. Trenta’s module.platform contains module.platform.module.network, which the graph draws as a container inside a container and the lists label module.network under module.platform.
• Instances: Trenta has aws_ssm_parameter.store_hours["downtown"] and friends from for_each, and aws_subnet.private[0] and friends from count, in state and in the plan (which adds one of each). Its raw terraform.tfstate carries the same instances, so it also exercises the raw path’s address spelling.
• Drift, moves and replace paths: Trenta’s plan records that aws_route53_zone.shop was edited outside Terraform (resource_drift) and reverts it, moves aws_dynamodb_table.loyalty_cards into module.ordering (previous_address), and names fifo_queue as the attribute forcing the queue replacement (replace_paths). tiv does not show these yet; the data is there for when it does.
• A second provider: Trenta’s module.storefront holds a random_id beside its AWS resources, so provider filters and per-module provider handling have something to distinguish.