ratification-queue-gen

Overview ¶

What "service family" means here, and what is approximated ¶

live/COVERAGE.md's weighting note names twelve families by their CloudFormation-registry shape (EC2/VPC is one CFN namespace, EC2 - VPC resources are filed there too; SQS/SNS and EKS/ECS are two namespaces each, named together because both members are individually small; ELB merges CloudFormation's classic ElasticLoadBalancing namespace with ElasticLoadBalancingV2). This generator resolves a type's CFN namespace from live/mapping.json's own cfn_type field (or fold_parent's, for a fold child) - the same registry evidence tools/row-gen's own Service field already batches by (classify.go's serviceOf) - and matches it against those twelve names first.

Just over two thirds of the pending-ratification population carries no CFN model at all (live/mapping.json's via is cfn-unmodeled or tf-only - COVERAGE.md's own "of those, with no CloudFormation model" row), so a CFN-only rule would leave most of the queue in one large "no family" bucket. For those types, and only for those, this generator falls back to the Terraform type's own prefix (the token right after "aws_") and a small, hand-checked alias table (priorityPrefixFallback below) that maps the prefixes actually observed in today's pending-ratification set onto the twelve named families - aws_default_vpc and aws_ebs_snapshot have no CFN model but are unmistakably EC2/VPC, for instance. That table is therefore a description of what this generator found in the pending set at build time, not a general AWS service taxonomy; re-run it after a provider bump and a genuinely new prefix will fall through to the non-priority path below rather than being silently mis-filed.

A type outside the twelve named families keeps its resolved CFN namespace as its family name when it has one (batches such as "Redshift" or "AppMesh"), and otherwise its own TF prefix, capitalized, as a stand-in family name (batches such as "Quicksight" or "Pinpoint"). Those non-priority families are ordered after the twelve named ones, by pending-type count descending and then alphabetically - a determinism tie-break, not a measured usage claim; COVERAGE.md's weighting note states an order only for the twelve it names.

Command ratification-queue-gen writes live/ratification-queue.json, issue #426's ordered worklist: every type live/readiness.json marks pending-ratification, batched by service family in the priority order live/COVERAGE.md's "usage-weighted summary" paragraph states (EC2/VPC, S3, IAM, Lambda, RDS, DynamoDB, SQS/SNS, EKS/ECS, ELB, Route53, KMS, CloudWatch first), with the evidence pointer for each type - PROPOSE's own pastable block where it covers the type, live/readiness.json's own facts otherwise.

go run ./tools/ratification-queue-gen

This tool ratifies nothing: it does not touch internal/live/identity/table_generated.go, tools/row-gen/ratified.json or live/readiness.json itself. It reads live/readiness.json and live/mapping.json (both committed artifacts) and runs `go run ./tools/row-gen -propose` as a read-only subprocess the same way tools/admission-pipeline does (propose.go's own doc comment: row-gen is its own package main, so every caller shells out rather than importing). See build.go's package doc comment for the family-assignment rule and what it approximates.