feat: mine reusable AeroSim channel lessons

references/authority-precedence-and-concurrent-evidence.md

@@ -0,0 +1,60 @@
+# Authority precedence and concurrent-evidence handling
+
+Use this reference when a scheduled Architecture run observes conflicting authority text across its invocation prompt, the installed project skill, Discord history, canonical repository data, or another concurrent agent's local work.
+
+## Precedence
+
+Apply the narrowest higher-authority instruction that governs the current run:
+
+1. System and developer instructions.
+2. The current user's invocation-local contract, including scheduled-job boundaries.
+3. The installed project-local skill and its authorization override.
+4. Verified human Discord decisions within the six authorized channels.
+5. Canonical remote default-branch records and exact remote PR artifacts.
+6. Bot reports, local branches, uncommitted diffs, and agent assertions.
+
+A project-local authorization override may supersede generic reference-skill gates, but it does not supersede a stricter current invocation. If the scheduled prompt says to work only on Features carrying explicit human `Approved for Solution` evidence, broad delegation or an installed override cannot relax that run.
+
+## Classification rules
+
+- Broad project leadership, PR-management authority, urgency, or a request asking why items remain Proposed is not item-specific approval when the invocation requires an exact Feature and exact target state.
+- An agent-authored approval, local staged transition, or report that a decision is “valid” is not remote authoritative lifecycle evidence unless the active contract explicitly permits delegated agent approval and the canonical decision record satisfies it.
+- A concurrent local diff has no remote authority. Record it as unpublished concurrent work, do not validate it as a PR, and do not let it change the current default-branch verdict.
+- A mutable installed skill may change during a run. Continue honoring the invocation snapshot and direct prompt that started the run; re-read the skill only to detect and report a contradiction, not to retroactively weaken the active contract.
+- If remote default remains compliant while concurrent unpublished work conflicts with the active gate, report default as `in sync` and disclose the unpublished contradiction separately. Do not create a competing PR.
+
+## Validator success does not resolve authority conflicts
+
+Repository validators may correctly prove schema integrity, actor allowlisting, hash chains, generated views, and build health while still accepting a delegated decision that the current invocation is forbidden to use. Treat these as separate questions:
+
+1. **Canonical integrity:** does the remote record satisfy the repository's current schema and trust model?
+2. **Invocation eligibility:** may this run act on that record under its narrower approval contract?
+
+A successful validator or exact-SHA CI result answers only the first question. When canonical default records say `Approved for Solution` through a delegated agent but the invocation requires explicit item-specific human approval:
+
+- report the canonical status and delegated actor exactly as stored;
+- state that the Feature is ineligible for semantic solution work in this run;
+- do not rewrite or roll back canonical lifecycle history merely to make it match the temporary run boundary;
+- do not let a coordination PR's prose that "approval authorizes Architecture" override the invocation;
+- keep structural/build health separate from semantic eligibility in the final verdict.
+
+If an unpublished solution worktree was created under the broader authority model, classify it as concurrent candidate work. Do not publish, complete, or validate it as the current run's deliverable; disclose its base SHA, publication state, and unresolved review findings when material. Avoid opening a competing Architecture PR while that worktree or an owning PR controls the same artifacts.
+
+## Evidence wording
+
+State all three dimensions separately:
+
+- **Current authoritative default:** branch, SHA, lifecycle state, decision actor/authority, and exact-default CI.
+- **Current run boundary:** the approval rule actually governing this invocation and whether the canonical item is eligible under it.
+- **Concurrent candidate state:** local/unpublished or remote PR, with its exact authority, base/head SHA, publication state, and evidence limitations.
+
+When canonical default contains delegated-agent solution or implementation decisions but the scheduled invocation requires exact human approval, use an explicit split verdict such as:
+
+```text
+Structural/build state: in sync at <branch>/<SHA>.
+Semantic eligibility for this run: blocked — canonical decisions were authored under delegated authority and no exact human item-specific approval was found.
+```
+
+Do not repeat a cross-channel bot summary such as “solutioning is complete,” “ready to build,” or “no blocker remains” without immediately qualifying that it describes canonical delegated state only and is not authorization under the current human-only run. A newer Scope/General reconciliation PR that changes only status prose may be substantive synchronization evidence, but if the Architecture tree and Architecture-relevant configuration are byte-identical to the previously validated merge, verify tree equality, validate the new exact default head, and report the authority split without creating an Architecture churn PR.
+
+Never phrase a local proposal as integrated, never call a broad delegation item-specific unless the active contract permits that interpretation, and never imply that passing repository validation makes a decision usable under a stricter invocation.