hecks 3.4.2 → 3.6.0

data/lib/hecks/projections/deploy/templates/fargate/owning_params.tmpl

@@ -0,0 +1,33 @@
+# The storehouse — @@owner_domain_name@@'s own live stack Outputs,
+# looked up at deploy time (the generated Makefile's own `deploy:`
+# target) via `aws cloudformation describe-stacks`, the identical
+# pattern `Lambda`'s own generated Makefile already uses for a
+# Shared-mode domain.
+OwningVpcId:
+  Type: AWS::EC2::VPC::Id
+OwningSubnetAId:
+  Type: AWS::EC2::Subnet::Id
+OwningSubnetBId:
+  Type: AWS::EC2::Subnet::Id
+# PUBLIC subnets, NOT OwningSubnetAId/OwningSubnetBId above — a
+# real, live deploy (a shared-database stack) found the ALB placed in
+# the private pair creates successfully and reports its target
+# health as healthy (health checks run from inside the VPC), yet
+# is completely unreachable from outside it:
+# OwningSubnetAId/OwningSubnetBId have MapPublicIpOnLaunch: false
+# and no Internet Gateway route. These two — resolved from the
+# owner stack's own PublicSubnetId/BastionSubnetId Outputs,
+# MapPublicIpOnLaunch: true with a real 0.0.0.0/0 -> igw route —
+# are the pair that actually works for an internet-facing ALB.
+# Service.NetworkConfiguration below still (correctly) uses the
+# private pair for the tasks themselves — only the ALB moves.
+OwningPublicSubnetAId:
+  Type: AWS::EC2::Subnet::Id
+OwningPublicSubnetBId:
+  Type: AWS::EC2::Subnet::Id
+OwningSecurityGroupId:
+  Type: AWS::EC2::SecurityGroup::Id
+OwningDatabaseEndpoint:
+  Type: String
+OwningDatabaseSecretArn:
+  Type: String

data/lib/hecks/projections/deploy/templates/fargate/template.yaml.tmpl

@@ -0,0 +1,281 @@
+# GENERATED by hecks deploy project @@domain@@ — re-run it to refresh
+# this file rather than hand-editing. Source: @@world_file@@'s own
+# deployed_to("AwsFargate") block.
+#
+# Plain CloudFormation, not SAM — deployed with
+# `aws cloudformation deploy`, never `sam deploy`. Self-contained
+# the same way `Lambda`'s own template is: this stack owns its own
+# private VPC, subnets, and RDS Postgres instance (unless
+# database "Shared"), not just the ECS service.
+AWSTemplateFormatVersion: '2010-09-09'
+Description: >
+  @@infra_name@@ — dispatched through hecks's rust/host, running as a
+  long-lived container on AWS Fargate, backed by its own private RDS
+  Postgres instance.
+@@parameters_block@@
+Resources:
+  @@network_resources@@
+
+  @@alb_sg_id@@:
+    Type: AWS::EC2::SecurityGroup
+    Properties:
+      VpcId: @@vpc_ref@@
+      GroupDescription: @@alb_sg_description@@
+      SecurityGroupIngress:
+        # pl-3b927c52 — com.amazonaws.global.cloudfront.origin-
+        # facing, AWS's own global, account-agnostic managed
+        # prefix list (confirmed: `aws ec2 describe-managed-
+        # prefix-lists`, OwnerId "AWS", same id in every
+        # account/region). NOT 0.0.0.0/0 — the whole reason
+        # @@distribution_id@@ above exists is Managed-
+        # CachingDisabled on every session-cookie-driven
+        # route; leaving the ALB itself open to the public
+        # internet on this same port would let anyone bypass
+        # that distribution (and its HTTPS) entirely and hit
+        # the plain-HTTP origin directly — the exact gap a
+        # code review caught the first time this resource was
+        # added.
+        - IpProtocol: tcp
+          FromPort: 80
+          ToPort: 80
+          SourcePrefixListId: pl-3b927c52
+
+  @@ingress_from_alb_id@@:
+    Type: AWS::EC2::SecurityGroupIngress
+    Properties:
+      GroupId: @@compute_security_group_ref@@
+      IpProtocol: tcp
+      FromPort: @@port_min@@
+      ToPort: @@port_max@@
+      SourceSecurityGroupId: !Ref @@alb_sg_id@@
+
+  @@ecr_repository_id@@:
+    Type: AWS::ECR::Repository
+    Properties:
+      RepositoryName: @@repository_name@@
+      ImageScanningConfiguration:
+        ScanOnPush: true
+
+  @@cluster_id@@:
+    Type: AWS::ECS::Cluster
+    Properties:
+      ClusterName: @@cluster_name@@
+
+  @@log_group_id@@:
+    Type: AWS::Logs::LogGroup
+    Properties:
+      LogGroupName: @@log_group_name@@
+      RetentionInDays: 30
+
+  # Always minted — HECKS_SERVE_MODE always runs web.rs, which
+  # panics on an empty SESSION_SECRET (seen live as a 502
+  # after a database cutover). rust/host fetches this at cold
+  # start (secrets.rs), never a plain env var.
+  @@session_secret_id@@:
+    Type: AWS::SecretsManager::Secret
+    Properties:
+      # TMPL:session_secret_properties
+      GenerateSecretString:
+        SecretStringTemplate: '{}'
+        GenerateStringKey: session_secret
+        PasswordLength: 64
+        ExcludePunctuation: true
+
+  # Pulls the image and writes CloudWatch Logs — AWS's own managed
+  # AmazonECSTaskExecutionRolePolicy already covers both (ECR auth
+  # + GetDownloadUrlForLayer, and logs:CreateLogStream/PutLogEvents);
+  # the one grant that policy does NOT cover is fetching this
+  # domain's own database secret, added below, least-privilege,
+  # scoped to the single secret ARN this stack itself depends on.
+  @@execution_role_id@@:
+    Type: AWS::IAM::Role
+    Properties:
+      AssumeRolePolicyDocument:
+        Version: '2012-10-17'
+        Statement:
+          - Effect: Allow
+            Principal: { Service: ecs-tasks.amazonaws.com }
+            Action: sts:AssumeRole
+      ManagedPolicyArns:
+        - arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
+      Policies:
+        # TMPL:execution_database_grant
+        # TMPL:extra_execution_policies
+
+  # The container's OWN runtime permissions — rust/host fetches
+  # DB_SECRET_ARN itself, over the AWS SDK, the same "never let
+  # CloudFormation/ECS configuration see it resolved" posture
+  # `Lambda`'s own generated template already holds to (a
+  # `Secrets:` ContainerDefinition property would resolve it
+  # into a plain environment variable instead).
+  @@task_role_id@@:
+    Type: AWS::IAM::Role
+    Properties:
+      AssumeRolePolicyDocument:
+        Version: '2012-10-17'
+        Statement:
+          - Effect: Allow
+            Principal: { Service: ecs-tasks.amazonaws.com }
+            Action: sts:AssumeRole
+      Policies:
+        - PolicyName: @@db_secret_policy_name@@
+          PolicyDocument:
+            Version: '2012-10-17'
+            Statement:
+              - Effect: Allow
+                Action: secretsmanager:GetSecretValue
+                Resource: !Sub "${@@db_secret_ref@@}"
+        - PolicyName: SessionSecretRead
+          PolicyDocument:
+            Version: '2012-10-17'
+            Statement:
+              - Effect: Allow
+                Action: secretsmanager:GetSecretValue
+                Resource: !Ref @@session_secret_id@@
+        @@oauth_task_policy_marker@@
+        # TMPL:cross_domain_fargate_policies
+        # TMPL:extra_task_policies
+
+  @@task_definition_id@@:
+    Type: AWS::ECS::TaskDefinition
+    Properties:
+      Family: @@family_name@@
+      RequiresCompatibilities: [FARGATE]
+      NetworkMode: awsvpc
+      # ARM64, not Fargate's own x86_64 default — matching the
+      # generated Makefile's own aarch64-unknown-linux-gnu build
+      # (below) and Lambda's own arm64 toolchain this reuses; a
+      # container built for the wrong arch fails at task start,
+      # not at build time, so this has to agree with the image
+      # docker-build actually pushes.
+      RuntimePlatform:
+        CpuArchitecture: ARM64
+        OperatingSystemFamily: LINUX
+      Cpu: "@@cpu@@"
+      Memory: "@@memory@@"
+      ExecutionRoleArn: !GetAtt @@execution_role_id@@.Arn
+      TaskRoleArn: !GetAtt @@task_role_id@@.Arn
+      ContainerDefinitions:
+        - Name: @@container_name@@
+          Image: !Sub "${@@ecr_repository_id@@.RepositoryUri}:${@@tag_parameter@@}"
+          # TMPL:domain_essential
+          PortMappings:
+            - ContainerPort: @@port@@
+          LogConfiguration:
+            LogDriver: awslogs
+            Options:
+              awslogs-group: !Ref @@log_group_id@@
+              awslogs-region: !Ref AWS::Region
+              awslogs-stream-prefix: @@container_name@@
+          Environment:
+            - Name: HECKS_DOMAIN
+              Value: @@declared_domain_name@@
+            - Name: HECKS_ERA
+              Value: "1"
+            - Name: PORT
+              Value: "@@port@@"
+            # `rust/host/src/server.rs`'s own top-of-`main`
+            # switch — without it, this container runs as the
+            # Lambda custom-runtime process `Lambda`'s own
+            # generated binary always has, which blocks
+            # forever polling a Runtime API that doesn't exist
+            # here, never answering the health check or
+            # anything else on `port`.
+            - Name: HECKS_SERVE_MODE
+              Value: "1"
+            # `web "Rust"` vs `web "None"` is otherwise inert
+            # here today — both modes generate the identical
+            # task/service/target-group shape, since a Fargate
+            # task always answers HTTP on `port` for dispatch
+            # requests either way. Passed through so
+            # `rust/host`'s own server loop (server.rs) can
+            # read it and decide whether to also serve the
+            # public web UI in-process, the same `web`-shaped
+            # choice `Lambda`'s own `rust_web` already makes
+            # for the Lambda path.
+            - Name: HECKS_WEB
+              Value: @@web@@
+            # HECKS_WASM_PATH/HECKS_IR_PATH — main.rs requires
+            # both unconditionally at boot (ir::ir().ok_or(...)?,
+            # no fallback, and HECKS_WASM_PATH for every
+            # dispatch) regardless of `web`/HECKS_SERVE_MODE. A
+            # container built with neither set crashes before
+            # ever reaching its own serve loop — found live
+            # deploying a real domain container, fixed here so every Fargate domain ships
+            # both sidecars by default. Paths match the
+            # Dockerfile's own COPY destinations, below.
+            - Name: HECKS_WASM_PATH
+              Value: @@sidecar_dir@@/@@domain_name@@.wasm
+            - Name: HECKS_IR_PATH
+              Value: @@sidecar_dir@@/@@domain_name@@.ir.json
+            - Name: SESSION_SECRET_ARN
+              Value: !Ref @@session_secret_id@@
+            - Name: HECKS_CHECKOUT_DOMAIN
+              Value: @@declared_domain_name@@
+            @@oauth_task_env_marker@@
+            # TMPL:db_env
+            # TMPL:domain_env
+        # TMPL:extra_containers
+
+  @@target_group_id@@:
+    Type: AWS::ElasticLoadBalancingV2::TargetGroup
+    Properties:
+      TargetType: ip
+      Port: @@port@@
+      Protocol: HTTP
+      VpcId: @@vpc_ref@@
+      HealthCheckPath: @@health_path@@
+      HealthCheckPort: "@@port@@"
+      # TMPL:target_group_attributes
+
+  @@alb_id@@:
+    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
+    Properties:
+      Name: @@alb_name@@
+      Scheme: internet-facing
+      Type: application
+      SecurityGroups: [!Ref @@alb_sg_id@@]
+      Subnets: @@alb_subnets@@
+
+  @@listener_id@@:
+    Type: AWS::ElasticLoadBalancingV2::Listener
+    Properties:
+      LoadBalancerArn: !Ref @@alb_id@@
+      Port: 80
+      Protocol: HTTP
+      DefaultActions:
+        - Type: forward
+          TargetGroupArn: !Ref @@default_target_group_id@@
+
+  # TMPL:extra_target_groups
+  @@service_id@@:
+    Type: AWS::ECS::Service
+    DependsOn: @@depends_on@@
+    Properties:
+      ServiceName: @@service_name@@
+      Cluster: !Ref @@cluster_id@@
+      TaskDefinition: !Ref @@task_definition_id@@
+      DesiredCount: @@desired_count_value@@
+      LaunchType: FARGATE
+      # TMPL:service_tuning
+      NetworkConfiguration:
+        AwsvpcConfiguration:
+          AssignPublicIp: DISABLED
+          Subnets: @@service_subnets@@
+          SecurityGroups: [@@compute_security_group_ref@@]
+      LoadBalancers:
+        - ContainerName: @@container_name@@
+          ContainerPort: @@port@@
+          TargetGroupArn: !Ref @@target_group_id@@
+        # TMPL:extra_load_balancers
+
+  # TMPL:distribution
+
+  # TMPL:extra_resources
+Outputs:
+  ServiceUrl:
+    Value: !Sub "http://${@@alb_id@@.DNSName}"
+  CloudFrontDomain:
+    Value: !GetAtt @@distribution_id@@.DomainName
+  @@output_lines@@
+  # TMPL:extra_outputs

data/lib/hecks/projections/deploy/templates/lambda/Makefile.tmpl

@@ -0,0 +1,218 @@
+# GENERATED by hecks deploy project @@domain@@ — re-run it to refresh
+# this file rather than hand-editing.
+#
+# `sam build` invokes the build-<LogicalId> target below (SAM's own
+# BuildMethod: makefile convention — see template.yaml's Metadata).
+# `cargo lambda` (https://www.cargo-lambda.info) cross-compiles
+# rust/host for arm64 Lambda without Docker or a hand-configured
+# cross-linker — install once with `pip3 install cargo-lambda` or
+# `brew install cargo-lambda`.
+
+HOST_DIR := @@host_dir@@
+# `domain_name`, matching `hecks build_wasm`'s own target_mod_name
+# (a Rust-build-pipeline naming convention, not AWS resource
+# identity — see HECKS_WASM_PATH's own comment above).
+WASM     := @@wasm_path@@
+
+build-@@logical_id@@:
+	@command -v cargo-lambda >/dev/null 2>&1 || { \
+		echo "cargo-lambda isn't installed. Install it once with: pip3 install cargo-lambda"; \
+		exit 1; \
+	}
+# ALWAYS rebuilt, never `test -f $(WASM) || ...` — that guard only
+# checked EXISTENCE, not staleness, so a wasm built once at the
+# start of a work session silently kept getting deployed through
+# every later kernel change (a real, live bug: this cost a stale
+# deploy against a wasm that predated the kernel's own "mutations"
+# field). `hecks build_wasm` recompiles fast enough that "always
+# rebuild" is the safe default, matching rust/host's own bootstrap
+# build just below, which was never guarded this way to begin with.
+	cd @@root@@ && HECKS_ENVIRONMENT=memory ruby exe/hecks build.build_wasm domain=@@domain@@ --wait
+	@rustup target list --installed 2>/dev/null | grep -qx aarch64-unknown-linux-gnu || rustup target add aarch64-unknown-linux-gnu
+# `rustup run stable`, not a bare `cargo lambda` — same reasoning
+# `hecks build_wasm`'s own Makefile-equivalent line holds itself to: a
+# `cargo`/`rustc` earlier on PATH than rustup's own shims (Homebrew
+# installs one; common on this kind of machine) is a DIFFERENT
+# toolchain that never saw `rustup target add`, and fails with
+# "can't find crate for `core`" for the cross target even though
+# `rustup target list --installed` reports it present.
+# macOS -> Linux arm64 cross-compiling by default routes through
+# zig (cargo-lambda's own bundled cargo-zigbuild) — every zig
+# release checked so far (0.15.2, 0.16.0) rejects
+# `-Wl,--fix-cortex-a53-843419`, a flag rustc's own
+# aarch64-unknown-linux-gnu target emits unconditionally: "error:
+# unsupported linker arg: --fix-cortex-a53-843419", found live on
+# THIS domain's own very first real deploy attempt (upstream:
+# https://github.com/ziglang/zig/issues, no fix released yet as of
+# this comment). Not fixable by a flag here — it's zig's own `zig
+# cc` argument-translation layer refusing before rustc's link step
+# ever runs. If this build fails with that error, cargo-lambda has
+# a real, documented non-zig, non-Docker fallback: `-c cargo` (or
+# `CARGO_LAMBDA_COMPILER=cargo`) plus a real GNU cross-toolchain —
+# `brew tap messense/macos-cross-toolchains && brew install
+# aarch64-unknown-linux-gnu` (this flag has worked in real
+# binutils/LLD since 2018; only zig's own translation of it is the
+# gap), then set `CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=
+# aarch64-linux-gnu-gcc` with that toolchain's own bin/ on PATH.
+# Confirmed working end to end (a real `sam deploy` against a real
+# Lambda) the same day this comment was written.
+	cd $(HOST_DIR) && rustup run stable cargo lambda build --release --arm64
+	cp $(HOST_DIR)/target/lambda/bootstrap/bootstrap $(ARTIFACTS_DIR)/bootstrap
+# UNCONDITIONAL, not gated on rust_web -- same reason HECKS_IR_PATH
+# itself is unconditional above: main.rs's own boot sequence reads
+# the IR for every domain regardless of web mode, so the sidecar
+# file this env var points to has to actually be in the package
+# too, or the env var alone just changes the crash from "not set"
+# to "not found".
+	cp $(WASM) $(ARTIFACTS_DIR)/@@domain_name@@.wasm
+	cp @@ir_path@@ $(ARTIFACTS_DIR)/@@domain_name@@.ir.json
+
+# `sam build <resource>` WIPES .aws-sam/build/ entirely before
+# building just the one resource named -- confirmed live: building
+# @@web_logical_id@@ second left NO @@logical_id@@/ directory behind at
+# all, and reverted its OWN built CodeUri back to the raw, unbuilt
+# source value ("../.." -- CodeUri: . resolved two directories up
+# from .aws-sam/build/template.yaml). `sam deploy` then zips THAT
+# directory verbatim as @@logical_id@@'s own code -- a real, live
+# deploy shipped @@web_logical_id@@'s own source tree (Gemfile,
+# lambda_handler.rb, even .env.local) as @@logical_id@@'s Lambda
+# package this way, caught by downloading the actually-deployed
+# code and finding @@web_logical_id@@'s file tree inside it.
+# `deploy:`'s own two separate `sam build <resource>` calls can
+# never both survive in .aws-sam/build/ at once — this target
+# re-populates @@logical_id@@'s build directory from the SAME
+# already-built bootstrap+wasm build-@@logical_id@@ just produced
+# (untouched by the second sam build call — only .aws-sam/build/
+# itself gets wiped, never $(HOST_DIR)/target or $(WASM)) and
+# repoints the built template's CodeUri back at it.
+.PHONY: restore-@@logical_id@@-build
+restore-@@logical_id@@-build:
+	@mkdir -p .aws-sam/build/@@logical_id@@
+	cp $(HOST_DIR)/target/lambda/bootstrap/bootstrap .aws-sam/build/@@logical_id@@/bootstrap
+	cp $(WASM) .aws-sam/build/@@logical_id@@/@@domain_name@@.wasm
+	cp @@ir_path@@ .aws-sam/build/@@logical_id@@/@@domain_name@@.ir.json
+	ruby -e 'lines = File.readlines(".aws-sam/build/template.yaml"); start = lines.index { |l| l.strip == "@@logical_id@@:" } or raise "restore-@@logical_id@@-build: @@logical_id@@ resource not found in built template"; idx = (start+1...lines.length).find { |i| lines[i] =~ /CodeUri:/ } or raise "restore-@@logical_id@@-build: no CodeUri line found under @@logical_id@@"; lines[idx] = lines[idx].sub(/CodeUri:.*/, "CodeUri: @@logical_id@@"); File.write(".aws-sam/build/template.yaml", lines.join)'
+
+# `make verify-parity-@@logical_id@@` — closes the exact gap the
+# equivalence-gap plan's own Phase 8 named: parity was checked ONLY
+# against CI's fixed test corpus, completely decoupled from what a
+# real `sam deploy` actually ships — `hecks check_conformance` (the
+# differential harness, docs/decisions/0010-ruby-is-the-reference-
+# implementation.md) had never once been run against a specific
+# compiled deploy artifact. Runs it here, for real, against
+# $(WASM) -- the EXACT file `build-@@logical_id@@` (above) just built
+# and `deploy:` (below) is about to ship -- not a corpus-wide `cargo
+# build`'s own separate binary. `hecks check_conformance --wait` exits non-zero
+# on any mismatch, which this target lets propagate uncaught: a real
+# divergence between THIS artifact and Ruby's own reading of the
+# identical source blocks `make deploy` before `sam deploy` ever
+# runs, the same way a failing build already would.
+#
+# `spec/corpus/@@domain_name@@.json` is this domain's OWN pinned
+# fuzzer-replay script (the same shape `hecks fuzz`/`hecks run` already
+# use) -- if a domain doesn't have one yet, this warns LOUDLY and
+# continues rather than either silently skipping (this project's own
+# standing rule against a silent gap reading as full coverage) or
+# blocking every deploy of a domain nobody has written one for yet.
+#
+# SECOND HALF, BELOW — `hecks fuzz_conformance`, ADR 0037's own fuzz
+# bridge pointed at this exact $(WASM). A pinned script only proves
+# "matches Ruby on the cases we thought to write down" (ADR 0039's own
+# honest framing); the fuzz bridge is what actually FOUND Findings 1-6.
+# Deliberately WARN-ONLY (`-@`, not `@`) for now: ADR 0037 already
+# catalogues real, confirmed, not-yet-fixed divergences (Findings 3 and
+# 5) that fire on ordinary generated sequences for more than one real
+# domain today, so making this a hard blocker before those are closed
+# would turn every affected domain's `make deploy` red for a reason
+# this target can't yet point at a fix for. Flip `-@` to `@` once ADR
+# 0037's open findings are closed and this stops firing in practice.
+.PHONY: verify-parity-@@logical_id@@
+verify-parity-@@logical_id@@:
+	@if [ -f @@root@@/spec/corpus/@@domain_name@@.json ]; then \
+		cd @@root@@ && HECKS_ENVIRONMENT=memory ruby exe/hecks build.check_conformance domain=@@domain@@ script=spec/corpus/@@domain_name@@.json artifact=$(WASM) --wait; \
+	else \
+		echo "verify-parity-@@logical_id@@: no spec/corpus/@@domain_name@@.json -- SKIPPING the pre-deploy Ruby/Rust parity check, nothing to compare $(WASM) against. Write one (hecks fuzz/hecks run's own script shape) before this domain's next deploy."; \
+	fi
+	@echo "verify-parity-@@logical_id@@: fuzzing $(WASM) against generated sequences (ADR 0037's bridge, WARN-ONLY -- see this target's own comment)..."
+	-@cd @@root@@ && HECKS_ENVIRONMENT=memory ruby exe/hecks build.fuzz_conformance domain=@@domain@@ artifact=$(WASM) --wait
+
+# `make mint-era` — takes @@stack_name@@'s RDS instance from freshly
+# created to "era 1 minted, ready for HECKS_DOMAIN/HECKS_ERA to
+# resolve" (template.yaml's own env vars already assume era 1 —
+# this is what makes that true). Run ONCE per fresh database, before
+# the first real `sam deploy` of the Lambda itself; safe to re-run
+# (a second boot against an already-held era 1 is a no-op — see
+# era_resolver.rb's own quiet-reboot branch). Stands up bastion.yaml
+# as its own sibling stack, uses it for one Ruby boot over an SSM
+# tunnel, then deletes it — nothing from this target is left running
+# afterward.
+ROOT      := @@root@@
+DOMAIN    := @@domain@@
+STACK     := @@stack_name@@
+BASTION_STACK := @@stack_name@@-bastion
+
+mint-era:
+@@mint_era_recipe@@
+
+# `make scaffold-translation` — run this when a deploy's own
+# pre-flight boot check (or `make mint-era` directly) refuses with
+# "the shape changed (era N) and no translation edge covers it".
+# Diffs the held era against the current bluebook over the same
+# bastion tunnel mint-era uses and WRITES a translations/*.bluebook
+# edge file into this domain's own repo — confident rules inline,
+# genuine ambiguities as `unresolved` lines a human has to resolve by
+# hand (a rename, a drop, a compute — never guessed). Review the
+# written file, then `make translation-audit`.
+scaffold-translation:
+@@scaffold_translation_recipe@@
+
+# `make translation-audit` — verifies a written (or still-pending)
+# translation edge over the same tunnel: every translated state
+# against the new era's own types/invariants/lifecycle, the compiled
+# SQL against the port's own reference transform, and a before/after
+# sample of real records printed for human review. Re-run
+# `make deploy` (or `make mint-era`) once this passes — that's what
+# actually applies the edge; this only checks it.
+translation-audit:
+@@translation_audit_recipe@@
+
+# `make migrate-console-settings` — runs this domain's own
+# bin/migrate_console_settings (if it has one) over the same bastion
+# tunnel every other Postgres-touching target here uses, against the
+# real deployed database instead of local dev. A one-time data
+# migration, not a repeatable ops procedure like mint-era/scaffold-
+# translation — generated the same way regardless, per this
+# project's own standing rule against hand-run ops steps.
+migrate-console-settings:
+@@migrate_console_settings_recipe@@
+
+# `make rename-schema OLD=<old> NEW=<new>` — a native `ALTER SCHEMA
+# ... RENAME TO ...` over the same bastion tunnel mint-era uses,
+# for when this domain's own declared identity changes
+# (`formerly_known_as`) and its storage schema should follow. Purely
+# a Postgres namespace rename: every table/row/sequence inside it is
+# untouched, so this is safe to run against a live, in-use database
+# — the only requirement is that nothing else names the schema by
+# its OLD name at the moment this runs (this domain's own deployed
+# Lambda's HECKS_SCHEMA env var, most directly — run `make deploy`
+# right before or right after this, not with a long gap either way).
+rename-schema:
+@@rename_schema_recipe@@
+
+@@pg_native_section@@
+@@sync_oauth_section@@
+# `make deploy` — THE one command. Chains `sam build`, `sam deploy`
+# (creates/updates the VPC+RDS+Lambda stack), then `mint-era` (safe
+# to run every time — a second boot against an already-held era 1
+# is a no-op, era_resolver.rb's own quiet-reboot branch) so a fresh
+# database always ends this command with era 1 actually held, not a
+# separate step someone has to remember. No hand-run AWS CLI
+# sequence anywhere in this path.
+@@oauth_note@@
+@@shared_note@@
+.PHONY: deploy mint-era
+deploy:
+@@build_recipe@@
+@@predeploy_bridge@@
+@@deploy_recipe_lines@@
+	$(MAKE) mint-era

data/lib/hecks/projections/deploy/templates/lambda/aurora_depends.tmpl

@@ -0,0 +1,18 @@
+
+    # `{{resolve:secretsmanager:...}}` dynamic references do NOT
+    # create an implicit CloudFormation dependency on the referenced
+    # resource (documented AWS behavior) -- @@logical_id@@'s own
+    # Environment resolves one against @@db_id@@Secret below. A plain
+    # `DependsOn: @@db_id@@Secret` alone (CREATE_COMPLETE before this
+    # resource's own update starts) still hit a real, live, repeatable
+    # "Secrets Manager can't find the specified secret
+    # (ResourceNotFoundException)" -- CREATE_COMPLETE from
+    # CloudFormation's own perspective doesn't guarantee the secret is
+    # yet READABLE via a dynamic reference from a DIFFERENT resource's
+    # own concurrent update (AWS-side eventual consistency, not a
+    # CloudFormation ordering bug `DependsOn` alone can close).
+    # Chaining through @@db_id@@Cluster too -- which ALSO reads this
+    # secret, and whose own RDS-side update takes real, substantial
+    # wall-clock time to apply -- gives that propagation window time
+    # to close before @@logical_id@@'s own resolution is attempted.
+    DependsOn: [@@db_id@@Secret, @@db_id@@Cluster]

data/lib/hecks/projections/deploy/templates/lambda/build_dispatch_none.tmpl

@@ -0,0 +1,10 @@
+	# ONE build only -- dispatch "None" means there is no
+	# @@logical_id@@ of any kind (no cargo-lambda, no rust artifact, no
+	# verify-parity: nothing rust/host-shaped for this domain at all),
+	# so unlike every other WebFunction-carrying domain there is no
+	# second build to protect from `sam build <resource>`'s own
+	# WIPES-.aws-sam/build/-first behavior (build-@@logical_id@@'s own
+	# sibling comment on why that matters for domains that DO have one)
+	# and nothing to restore afterward.
+	sam build --use-container @@web_logical_id@@
+	$(MAKE) patch-pg-native

data/lib/hecks/projections/deploy/templates/lambda/build_pg.tmpl

@@ -0,0 +1,15 @@
+	# TWO SEPARATE builds, not one `--use-container` run -- that flag is
+	# global to `sam build`, but @@logical_id@@ deliberately builds on
+	# THIS machine's own toolchain (cargo-lambda already cross-compiles
+	# to arm64 without a container -- build-@@logical_id@@'s own comment
+	# on why), which a generic provided.al2023 container doesn't have
+	# at all (a real, live "Make Failed" caught this). Only @@web_logical_id@@
+	# needs the container, to cross-compile pg's native extension for
+	# Amazon Linux -- `sam build <resource>` WIPES .aws-sam/build/ before
+	# building just the one named, so @@logical_id@@'s own build gets
+	# restored below (restore-@@logical_id@@-build's own comment on why).
+	sam build @@logical_id@@
+	sam build --use-container @@web_logical_id@@
+	$(MAKE) restore-@@logical_id@@-build
+	$(MAKE) patch-pg-native
+	$(MAKE) verify-parity-@@logical_id@@

data/lib/hecks/projections/deploy/templates/lambda/build_plain.tmpl

@@ -0,0 +1,2 @@
+	sam build
+	$(MAKE) verify-parity-@@logical_id@@

data/lib/hecks/projections/deploy/templates/lambda/build_web.tmpl

@@ -0,0 +1,11 @@
+	# TWO SEPARATE builds -- @@web_logical_id@@ has no native extension to
+	# cross-compile (no `pg` in @@domain@@/Gemfile.lock), so a plain `sam
+	# build` targets it fine; @@logical_id@@ still gets its own `sam build
+	# <resource>` first, then restored below -- `sam build <resource>`
+	# WIPES .aws-sam/build/ before building just the one named, so the
+	# second call here would otherwise erase @@logical_id@@'s own build
+	# (restore-@@logical_id@@-build's own comment on why).
+	sam build @@logical_id@@
+	sam build @@web_logical_id@@
+	$(MAKE) restore-@@logical_id@@-build
+	$(MAKE) verify-parity-@@logical_id@@

data/lib/hecks/projections/deploy/templates/lambda/env_blind_guard.tmpl

@@ -0,0 +1,4 @@
+	@if [ -z "$$ALLOW_LOCAL_DB" ]; then \
+		echo "REFUSING: @@script@@ resolves its OWN database connection from @@domain@@'s .world file, NOT from DATABASE_URL/HECKS_SCHEMA -- opening a real tunnel to @@stack_name@@'s production RDS instance below would silently scaffold/audit the LOCAL dev database instead and report success (see this recipe's own comment, above, for the confirmed root cause). Set ALLOW_LOCAL_DB=1 to run @@verb@@ against @@domain@@'s local .world-declared database on purpose (e.g. to exercise the scaffold/audit logic itself); otherwise run this for real against production via the manual tunnel path mint-era's own comment describes."; \
+		exit 1; \
+	fi