============================================================
ONBOARDING CROSS-STACK HANDOFFS
Version: 0.1.0-ONBOARDING-HANDOFFS-CANDIDATE
Status: DRAFT / NON-MUTATING PATCH DIRECTIVES / NON-CANONICAL
Authority: AGLA / ONBOARDING_STACK
Mutation Policy: VERSION-CONTROLLED ONLY
Class: AGLA / ONBOARDING / CROSS_STACK_INTEGRATION
============================================================


I. PURPOSE
============================================================

This artifact stages the cross-stack changes needed for ONBOARDING.

It is intentionally non-mutating in this sprint. Existing A/T/E/SK/F/G/H/D/I
stack artifacts are not rewritten here. These directives identify the AREPO
and SATOR hooks that may be applied in a later patch after review.


II. GENERAL HANDOFF LAW
============================================================

When a target stack is invoked from ONBOARDING context:

    ONBOARDING may declare the target bootstrap.
    ONBOARDING may drill the user's understanding.
    ONBOARDING may block counterfeit execution.
    ONBOARDING must not execute the target OPERA.

The target stack remains authoritative for its own:

    TENET doctrine
    ROTA structure
    AREPO admissibility
    OPERA execution
    SATOR mediation


III. REGISTER HANDOFF LAW
============================================================

If a request arrives with ritualistic, oath-like, or juridic register, target
stacks should treat that register as a possible developer/operator signal.

The signal increases care; it does not create authority.

Target stacks should not teach users to reproduce protected register. They
should preserve it in developer-facing records and translate it into source,
admissibility, and fidelity constraints in tutorial-facing mediation.


IV. AREPO HOOK TEMPLATE
============================================================

Candidate insertion target:

    AREPO_<STACK>_InputAdmissibility.md

Candidate section:

    ONBOARDING HANDOFF ADMISSIBILITY

Candidate rule:

    If a request arrives with ONBOARDING context, AREPO_<STACK> may admit
    bootstrap reinforcement and tutorial inspection, but must not treat that
    admission as target OPERA execution admission.

Candidate statuses:

    ONBOARDING_BOOTSTRAP_REINFORCEMENT_ADMITTED
    ONBOARDING_REPEAT_REQUIRED
    ONBOARDING_BLOCKED_TARGET_EXECUTION
    ONBOARDING_AUXILIARY_DEPENDENCY_REQUIRED


V. SATOR HOOK TEMPLATE
============================================================

Candidate insertion target:

    SATOR_<STACK>_OutputRequirements.md

Candidate section:

    ONBOARDING HANDOFF MEDIATION

Candidate rule:

    If a request arrives with ONBOARDING context, SATOR_<STACK> may present
    the bootstrap, class focus, and next lawful action, but must include:

        This is bootstrap reinforcement, not OPERA execution.

    If protected register appears, SATOR_<STACK> should preserve the
    developer signal but avoid converting ritualistic language into ordinary
    user-facing prompt instruction.


VI. STACK-SPECIFIC HANDOFFS
============================================================

STACK A:
    AREPO hook must block A-as-Bonitas collapse.
    SATOR hook must teach A as pre-dignity regime and BCD before EFGHIK.

STACK T:
    AREPO hook must require relata and frame for execution-shaped requests.
    SATOR hook must teach relation/non-being distinction.

STACK E/Q:
    AREPO hook must block answer expectation when the tutorial target is
    interrogative reduction.
    SATOR hook must teach question/non-answer distinction and OPERA Q as
    OPERA E/Q alias surface.

STACK SK/S:
    AREPO hook must block subject classification as answer.
    SATOR hook must teach subjects as domains of reference, not conclusions.

STACK F:
    AREPO hook must require locus discipline for TABULA-shaped requests.
    SATOR hook must teach TABULA is not table, dataset, lookup, or ontology.
    Auxiliary handoff: D for A/T articulation, I for mixed carrier identity.

STACK G:
    AREPO hook must block partial Evacuatio when closure is required.
    SATOR hook must teach finite deterministic dependency-closed closure.
    Auxiliary handoff: D and I when their dependency conditions appear.

STACK H:
    AREPO hook must block topology invention.
    SATOR hook must teach Multiplicatio as chamber combination under ROTA D.
    Auxiliary handoff: D/ROTA D mandatory; I when mixed A/T/E carrier identity
    appears.

STACK D:
    AREPO-equivalent handoff is dependency-only in the current artifact set.
    ONBOARDING must not route to standalone OPERA D.
    SATOR-style mediation must say D is auxiliary and dependency-critical.

STACK I:
    AREPO-equivalent handoff is dependency-only in the current artifact set.
    ONBOARDING must not route to standalone OPERA I.
    SATOR-style mediation must say I is auxiliary and dependency-critical.


VII. ROOT-CLASS HANDOFFS
============================================================

AREPO root class:
    Future root integration may recognize ONBOARDING as a tutorial admission
    owner, not as target OPERA admission owner.

SATOR root class:
    Future root integration may recognize ONBOARDING as a training surface for
    user onboarding and assistant bootstrap visibility.

SYSTEM_INDEX:
    Future promotion should register ONBOARDING only after deciding whether it
    remains an integration candidate, moves to `13_STACK_ADD_ONS`, or enters
    vanilla stack routing.


VIII. FINAL HANDOFF LAW
============================================================

ONBOARDING may train invocation of other stacks. It must not consume their
authority. Any applied patch must preserve target-stack ownership.

============================================================
END ONBOARDING CROSS-STACK HANDOFFS
============================================================