Module inner_door 

The inner door planner (R870-F23) — the service.toml + domain-manifest join that produces a passway PASSWAY_PATH_ROUTES_FILE.

What an inner door is, and what it is not

R870-F15 landed path routing in passway; R870-T18 gave it a config surface (a JSON mount table named by PASSWAY_PATH_ROUTES_FILE). Both are the consumer. This module is the producer: given a service’s declared components and the domain manifest that routes them, it answers “what mount table does this service’s own door need, if any”.

It is an inner door because it sits behind the service’s public one, on loopback. The public door owns a hostname and terminates TLS; the inner door owns one hostname’s paths and splits them across units that deploy independently. That split is the only thing it does — and it is the thing the public door structurally cannot do, because the public tier routes by SNI/Host and a request’s path is not visible until after that.

The join carries no new vocabulary

R870-F15 claimed the join needs nothing new, and that holds up. Every input already exists:

Field	Source
mount	ServiceComponent::mount, normalized by normalize_mount
headers	the DomainRoute whose route_path_prefix equals that mount
tier	ServiceComponent::deploy — the one thing R870-F23 added
upstreams	placement-time, so it is InnerDoorPlan::routes_file’s argument, not a config field

The mount/route agreement is not re-derived here: [CloudConfig::cross_ref_validate] already proves a component’s mount and its route’s path prefix are the same string, so the lookup below cannot silently mismatch — a config where it would have does not load.

The two admission rules

Both belong here, never to passway: passway proxies whatever PathRouter it is handed and has no view of how many components a service declares.

1. A service with one independently-deployed unit gets no inner tier at all. Enforced by construction — plan answers Ok(None) below two units, so there is no config to write and no process to supervise. That makes the negative assertable on the absence of a plan rather than on a site staying up, which is the only form of that assertion that can fail loudly.
2. A component cannot be both bundle-staged and its own workload. Enforced by DeployTier being one field with two values rather than two independent flags: the contradictory state has no spelling. What remains checkable — that two components do not claim one mount — lives in cross_ref_validate’s existing loop, widened rather than duplicated.

Grouping is by deployed UNIT, not by component

Every bundle-tier component of a service shares ONE bundle workload (config 1, R870-B11), so they contribute one upstream between them — DeployedUnit::Bundle. They still contribute their own mounts, because a mount is where the bundle stores that component’s output (app/dist/<mount>/) and because the domain manifest may give that path response headers the root does not have. So N bundle components produce N mounts and one unit, and it is the unit count that rule 1 keys on.

Structs

InnerDoorMount

One mount of an inner door’s table, before upstream addresses exist.

InnerDoorPlan

A service’s inner door, as configuration — everything but the addresses.

Enums

DeployedUnit

Which deployed thing serves a mount.

Constants

INNER_DOOR_BINARY

The passway binary every node carries, installed by the yubaba release tarball’s control_plane_install. The inner door is the same binary as the public door — one door implementation, two configurations, which is the property R870-F15 built path routing to preserve.

INNER_DOOR_HOST

The only address an inner door ever binds, and the only one the outer door ever dials it at. Literal rather than a parameter — see InnerDoorPlan::workload.

INNER_DOOR_PORT_HIGH

High end of the window listen_port picks from, inclusive.

INNER_DOOR_PORT_LOW

Low end of the window listen_port picks from, inclusive.

ROUTES_DIR

Where a node keeps generated route tables. Same directory the demux and http-router tables already live in.

ROUTES_SCHEMA_VERSION

schema_version of the route table this module writes. Must match passway’s path_routes_file::SCHEMA_VERSION; a mismatch is a boot failure on the door naming both numbers, which is the intended way for a producer/consumer skew to surface (see that module’s doc).

Functions

component_workload_ident

The mesh identity a DeployTier::Workload component registers its service record under.

listen_port

The loopback port a service’s inner door listens on — derived from the service name, so every apply of an unchanged tree renders the same number.

passway_mount

Translate a normalized mount ("", "app") to passway’s spelling ("", "/app").

plan

Plan the inner door for one service, or answer None when it should not have one.