Autoschematic

Some APIs do not expose the canonical resource ID until after creation. VPCs are a clear example. Let's see how the VpcConnector handles this.

Connector::op_exec() should return output values on creation:

// Assume we have the new id of some newly created resource
let new_vpc_id = ...
let mut outputs = HashMap::new();
outputs.insert(String::from("vpc_id"), Some(new_vpc_id.clone()));

Ok(OpExecResponse {
    outputs: Some(outputs),
    friendly_message: Some(format!("Created VPC {}", new_vpc_id)),
})

Autoschematic stores those outputs under .autoschematic/{prefix}/{addr}.out.json. Then, that virtual address aws/vpc/{region}/name.ron is decoded to the physical address aws/vpc/{region}/{vpc_id}.ron.

Once you have an output like vpc_id, the connector can translate a user-facing virtual address to the real physical address:

let Some(vpc_id) = addr.get_output(&self.prefix, "vpc_id")? else {
    return Ok(VirtToPhyResponse::NotPresent);
};

Ok(VirtToPhyResponse::Present(
    VpcResourceAddress::Vpc {
        region: region.into(),
        vpc_id,
    }
    .to_path_buf(),
))

Override Connector::addr_virt_to_phy() and Connector::addr_phy_to_virt() only when you need them.

Examples of resources that don't need virtual addressing:

• GitHub repositories
• S3 buckets
• resources whose path already contains the canonical remote identifier

The VPC connector also shows the deferred case: a child resource can return VirtToPhyResponse::Deferred(...) until the parent output exists.

Practical rules:

• Pick stable output keys. The VPC connector uses vpc_id, subnet_id, or security_group_id.
• Return those same keys as outputs from both get() and op_exec() when they are known.
• Keep virtual-to-physical logic close to the address hierarchy.

Reference files:

• autoschematic-connector-aws/vpc/src/connector.rs

Next: Skeletons, Docs, and Validation