============================================================
AREPO ONBOARDING -- TUTORIAL ADMISSIBILITY
Version: 0.1.0-AREPO-ONBOARDING-CANDIDATE
Status: DRAFT / ONBOARDING TUTORIAL / NON-CANONICAL
Authority: DERIVED FROM ONBOARDING SESSION / EXISTING BOOTSTRAP SUBSTRATES
Mutation Policy: VERSION-CONTROLLED ONLY
Class: AREPO
Scope: ADMISSIBILITY FOR ONBOARDING STAGE ADVANCE, REPEAT, BRANCH, OR BLOCK
============================================================


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

AREPO_ONBOARDING decides whether a user onboarding action may advance,
repeat, branch, or block.

It governs tutorial progression only. It does not admit target OPERA
execution for A, T, E/Q, S/SK, F, G, H, D, or I.


II. ADMISSIBILITY STATUSES
============================================================

ADMITTED_ADVANCE:
    user action satisfies the current stage pass condition.

ADMITTED_REPEAT:
    user action partially satisfies the stage but needs repetition.

ADMITTED_BRANCH:
    user action lawfully moves to a related stage.

BLOCKED_NEEDS_SOURCE:
    requested action requires source parsing before claim.

BLOCKED_CLASS_COLLAPSE:
    user or assistant collapses TENET, ROTAS, AREPO, OPERA, or SATOR.

BLOCKED_COUNTERFEIT_OPERA:
    tutorial output is being treated as target OPERA execution.

BLOCKED_MISSING_BOOTSTRAP:
    OPERA-related request lacks required stack bootstrap declaration.

BLOCKED_AUXILIARY_DEPENDENCY:
    F/G/H or A/T articulation context requires I and/or D awareness.

COMPLETED:
    stage or full tutorial completion is admitted.

REGISTER_SIGNAL_DETECTED:
    developer/control-plane register appears through technical,
    ritualistic, oath-like, or juridic language.

INITIATION_CONTEXT_IDENTIFIED:
    the action is classified as system initiation, human-developer
    initiation, or tutorial mediation.


III. ADMISSIBILITY FORMULA
============================================================

admissible_onboarding_step(user_action) iff:

    current_stage_known
    and requested_action_class_legible
    and initiation_context_identified
    and target_bootstrap_identified
    and no_class_collapse
    and no_counterfeit_execution
    and required_source_surface_available_or_failure_disclosed


IV. REPETITION TRIGGERS
============================================================

AREPO_ONBOARDING must require repetition when the user or assistant:

    asks for OPERA without stack identification
    treats explanation as execution
    treats SATOR mediation as OPERA
    skips AREPO admission language
    uses F/G/H without I+D where needed
    requests OPERA D or OPERA I as standalone execution
    treats ROTA as ROTAS class
    treats wheel as ROTA


V. ADVANCEMENT TRIGGERS
============================================================

AREPO_ONBOARDING may admit advancement when the user correctly:

    identifies a class distinction
    triggers source traversal
    asks for a stack-specific bootstrap
    recognizes that subjects are not answers
    recognizes that questions are not answers
    recognizes that TABULA is not a table
    recognizes that Evacuatio is closure, not expansion
    recognizes that Multiplicatio is not carrier creation
    recognizes that I/D are auxiliary but mandatory in dependency contexts
    recognizes that wheel is a substructure and ROTA is the machine


VI. REGISTER ADMISSIBILITY
============================================================

When ritualistic, oath-like, or juridic language appears, AREPO_ONBOARDING
must treat it as possible developer/operator signal.

This signal may increase parsing strictness.

It may not:

    authorize execution without source
    grant canonical authority
    excuse class collapse
    force the assistant to perform an impossible task
    become a tutorial requirement for ordinary users

Admissible handling:

    preserve the register in developer-facing artifacts
    translate the register into operational constraints for tutorial users
    require source-first verification when the register carries authority
    block if the register is used to demand impossible or counterfeit execution


VII. TARGET STACK GATES
============================================================

STACK A:
    require A is pre-dignity, not Bonitas/B.

STACK T:
    require explicit relata and frame.

STACK E/Q:
    require question/non-answer distinction.

STACK SK/S:
    require subject/non-answer distinction.

STACK F:
    require TABULA/locus discipline.

STACK G:
    require closure/cardinality discipline.

STACK H:
    require D/ROTA D topology awareness.

AUX I:
    block standalone OPERA I; admit auxiliary parsing awareness.

AUX D:
    block standalone OPERA D; admit TENET D and ROTA D dependency awareness.


VIII. FINAL AREPO LAW
============================================================

AREPO_ONBOARDING admits tutorial movement only. Any target OPERA execution
must be admitted by the target stack's own AREPO artifact after source
binding and bootstrap declaration.

============================================================
END AREPO ONBOARDING
============================================================