# Internet Scenario Extension Architecture

This document freezes where new Internet RU-acceptance cases may extend TiPoC.
It follows the third-layer lifecycle introduced by Issue #65 and prevents case
names from becoming execution branches.

## Capability classes

### Windowed operations

Big Query, Missing Index, and future independently scheduled interference
features use the existing operation lifecycle:

```text
core/operation
  generic contracts, registry, lifecycle, scheduling, artifact envelope

industries/internet/platform/operations/<capability>
  Internet business definition, typed config, workers, business receipt

projections/tidb/operations/internet/<capability>
  TiDB SQL/DDL, EXPLAIN validation, statement RU and plan evidence
```

The composition root registers each operation explicitly. `core/execution`
must not select a case by testcase ID, query ID, domain name, or CLI-specific
branch. A new domain-specific query is data owned by the operation package, not
a new executor.

### Base workload selection policies

Hotspot is not a windowed operation. It changes which prepared business subject
enters a root before the root is built, so it belongs to the shared Internet
runtime:

```text
industries/internet/platform/adapters/workload_profile.go
  generic workload-profile to typed Internet policy translation

industries/internet/platform/runtime/hotspot_contract.go
  immutable scenario/order-plan and bounded receipt contracts

industries/internet/platform/runtime/hotspot_selector.go
  one domain-neutral selector over prepared user/world authority

industries/internet/platform/runtime/hotspot_receipt.go
  shared observation, merge, and per-domain projection
```

Ride, Food, and Mart do not own hotspot implementations. Their existing
production root builders consume the one selected consumer and remain the only
business SQL authority.

## Combination rule

A combined case is configuration, not another capability. It may:

- select an existing Internet business subset;
- resolve multiple registered operations;
- select one compiled workload policy;
- validate declared conflicts and evidence completeness;
- aggregate links to the independent capability receipts.

It must not introduce `combined`, `case`, or testcase-ID branches into worker,
SQL, lifecycle, recovery, or cleanup code. If two capabilities cannot coexist,
the conflict belongs to typed operation metadata and fails before side effects.

The offline acceptance adapter follows the same rule:

```text
industries/internet/platform/acceptance
  capability contract registry
  paired configuration diff guard
  operation/hotspot receipt normalization
  bounded report-input selection

cmd/tipoc ru-acceptance internet-dry-run
  strict artifact decoding and immutable report-input publication only
```

This adapter cannot schedule SQL, mutate indexes, choose a hot key, or recreate
worker counters. It accepts only the generic Operation artifact index, the
operation-owned final receipts, selected-run domain receipts, and the offline
RU acceptance aggregate produced by Query Cost.

`acceptance.ProjectCase` removes manual E2E assembly: every registered switch
projects to the existing `contracts.OperationSpec`, and the hotspot switch
projects to the existing typed service-area config. The projection never
creates a combined operation or a testcase-specific runtime identifier.

## Growth guards

Every new Internet RU-acceptance capability must satisfy all of these checks:

1. One stable capability ID and one owning package.
2. Table-driven domain selection tests instead of copied Ride/Food/Mart tests.
3. No fixed database name or environment-specific SQL literal.
4. No execution switch on testcase IDs.
5. Canonical scenario bytes and digests remain unchanged when the capability is absent.
6. Recovery and rerun cleanup behavior is explicit and tested.
7. Receipt shape is bounded; detailed rows belong in referenced artifacts.
8. Combination coverage reuses independent capability entry points.

If a proposed case cannot follow these rules, it requires an architecture issue
before implementation rather than another branch in the current executor.