Establish and enforce ownership rules for Effection scope and middleware

[taras]

Story

As a component or provider author, I want clear, enforced rules for Effection
scope and middleware, so I can tell who owns a resource, who may influence an
operation, who may authorize it, and what becomes durable history.

Example

A component installs middleware around a GitHub operation.

The middleware may observe the request, narrow it, refuse it, or delegate it. Its
lexical position does not let it manufacture an approved GitHub mutation or a
durable completion record.

The component's Effection scope owns the lifetime of live resources used while
the operation runs. The selected GitHub provider owns execution and its
authoritative outcome. The journal records the durable fact accepted for replay.

Those responsibilities compose, but they are not interchangeable.

Ownership model

Use five separate questions:

Question	Owner
Who authored this work?	Source site, including caller-projected content
Who owns its live lifetime and cleanup?	Effection scope
Who may observe, narrow, redirect, refuse, or delegate it?	Public middleware
Who may execute it and determine its canonical outcome?	Canonical engine or selected provider terminal
What survives as accepted history?	Journal or effect transaction

The mnemonic is:

Source owns authorship; scope owns lifetime; middleware owns policy;
canonical execution owns authority; the journal owns history.

Consequences

• Lexical enclosure does not grant execution authority or durable ownership.
• Component nesting and Effection scope often align, but they answer different
  questions.
• Caller-authored projected content remains caller-authored while a callee's
  scope supplies context and lifetime.
• Stable contextual names let separately loaded package copies compose. They do
  not prove trust, identity, authority, or completion.
• Public middleware may route or refuse an authoritative operation. Its return
  value is not completion evidence.
• Reconstructed scope and middleware during replay are current ephemeral policy,
  not proof that a past effect occurred.

Ordinary return-valued middleware remains appropriate when the returned value is
the replaceable policy result and cannot establish authoritative execution or
durable truth.

Authoritative operations

When a public contextual value could otherwise manufacture execution,
persistent identity, or durable completion, use an execution-owned boundary
such as:

• a frozen invocation-specific request;
• a one-use request where repetition would be unsafe;
• a private provider terminal; or
• equivalent execution-owned state.

Public middleware may observe, refuse, and delegate the request. It cannot invoke
the private terminal or publish the canonical result. A fabricated request,
captured wrapper, or second loaded package copy authorizes nothing.

Do not apply this machinery to pure configuration, display, or another
intentionally replaceable result merely because it also uses middleware.

Repository audit

Audit production and test-support uses of:

• scoped, resource, useScope, and Scope.run;
• tasks spawned through captured scopes;
• Context and Api installation;
• middleware delegation; and
• provider or engine terminals.

For every distinct pattern, record:

1. the source site that authored the work;
2. the scope that owns resources and teardown;
3. the behavior public middleware may change;
4. the path that may author the canonical outcome; and
5. the record, if any, that becomes durable truth.

Classify correct patterns as examples. Identify violations including:

• redundant or incorrectly placed scopes;
• resources escaping into a broader captured scope without an ownership
  contract;
• replaceable contextual state used as identity, trust, authority, or completion
  evidence;
• public middleware manufacturing an authoritative result; and
• replay treating reconstructed policy as retained evidence.

Fix a violation here when the correction preserves settled behavior. If a fix
would change observable behavior, persistence, or a public API, create a focused
follow-up issue and link it. No known violation remains implicit.

Rules and guidance

For every rule:

• state the author decision and the failure it prevents;
• provide the smallest valid example;
• include a counterexample when syntax alone hides the ownership mistake;
• distinguish lifetime, policy, authority, and durability;
• put actionable coding rules in AGENTS.md;
• keep the complete model and rationale in architecture.md; and
• keep specifications focused on observable behavior.

Add a shared review checklist to the Architect, Planner, and Implementor guides.
It identifies the protected consequence, execution owner, settlement owner,
permitted middleware behavior, invocation identity, failure ordering, and any
contextual state that might be trusted incorrectly.

Register any new architecture term before using it as normative vocabulary.

Enforcement

Classify every established rule as:

1. Static: an AST pattern can reject the violation reliably.
2. Tested: behavior or conformance evidence can distinguish it.
3. Review-only: the decision depends on semantic context a linter cannot
   prove.

Add enabled local Oxlint rules for every reliable static class. Each rule has
focused valid and invalid fixtures covering relevant aliases, namespace imports,
shadowing, and nearby valid code.

Do not add name-only heuristics that diagnose code without proving the forbidden
shape.

A suppression applies only to the exact site and includes a comment naming the
ownership or lifetime invariant that makes it valid. File-wide and
directory-wide exemptions are not enforcement.

Rules that cannot be linted receive focused tests where observable and explicit
review guidance otherwise.

Acceptance

• The audit accounts for every distinct production pattern and intentional
  test-support variation.
• A reader can answer the five ownership questions independently for each
  pattern.
• The rules state explicitly that lexical enclosure does not grant authority.
• Projected-content authorship and dynamic scope are distinguished.
• Stable-name composition is not treated as security or durable identity.
• The private-terminal/request pattern is documented once with its required
  properties and limits.
• Pure configuration and display middleware remain appropriately simple.
• Replay accepts durable truth only through retained records and their admission
  checks.
• Every rule has a static, tested, or review-only enforcement classification.
• Every reliable static class has an enabled Oxlint rule and regression fixtures.
• Architect, Planner, and Implementor guidance share the same ownership
  checklist.
• Existing violations are corrected or linked to decision-ready follow-up
  issues.
• Architecture references one coherent model instead of repeating apparently
  conflicting explanations.

Existing evidence

Use existing regressions where they already distinguish the model:

• projected-content failure ownership (🔒 Let the region decide a projected content failure #446);
• bound-command request authority (✨ Bind a command's settled result so a document can decide on its exit code #447);
• foreground output routing versus journal retention (🚿 Stream a foreground command and keep what the boundary received #442);
• Workspace coordination; and
• Git-host reconciliation and loaded-copy composition.

Add lint fixtures and focused ownership regressions only for claims the existing
evidence does not prove.

Out of scope

• Creating a generic authority primitive merely because several tests look
  similar.
• Refactoring correct boundaries without an identified ownership failure.
• Adding behavior permutations that prove no distinct rule.