# ONBOARDING_STACK Transfer Review

Status: CANDIDATE / INTEGRATION-CANDIDATE REVIEW / NOT CANONICAL
Review date: 2026-05-23
Source share: https://chatgpt.com/share/6a12351e-8a6c-83e9-9cb7-273b1e159305
Extracted bundle: `00_EXTRACTED_FROM_CHATGPT_SHARE/`

## Extraction Result

The direct ChatGPT share link was reachable and returned the conversation embedded in ChatGPT application state. The extraction pass decoded that stream and wrote a raw candidate bundle into:

`AGLA_ArsGeneralisLlullApplied/_01_INTEGRATION_CANDIDATES/ONBOARDING_STACK/00_EXTRACTED_FROM_CHATGPT_SHARE/`

The bundle contains:

- `00_EXTRACTION_MANIFEST.md`: extraction manifest with source-string indexes, byte counts, and SHA-256 hashes.
- `01_AGLA_BOOTSTRAP_INPUT_V0_1.txt`: compact bootstrap input recovered from the conversation.
- `02_...` through `11_...`: root and stack-specific bootstrap/self-binding oath artifacts.
- `12_M2M_ONBOARDING_STACK_SPECIFICATION.md`: main implementation specification for a future onboarding/tutorial stack.
- `13_LAB_H_ONBOARDING_INITIALIZATION_STATE.md`: initial lab/onboarding state.
- `20_...` through `36_...`: read reports for stack and root-law context recovered from the conversation.

No extracted file is canon by extraction. Treat the bundle as provenance-bearing candidate material.

## Architectural Meaning

The recovered onboarding spec is useful for the modularization sprint because it frames onboarding as a tutorial and trigger-training layer, not as a replacement OPERA and not as new root law.

Its strongest architectural proposal is a future optional onboarding stack that trains users to invoke the existing modular surface correctly:

- root class order: `TENET -> ROTAS -> AREPO -> OPERA -> SATOR`
- source-first parsing before claims
- distinction between explanation and execution
- stack-specific bootstrap triggers for A, T, E/Q, SK/S, F, G, and H
- auxiliary dependency awareness for I and D
- suspension instead of simulated execution when a required OPERA or source artifact is missing

This fits the current modularization direction best as an integration candidate or add-on-style stack. It should not be merged into vanilla root law without a separate promotion decision.

## Candidate Materialization Shape

The extracted spec suggests a future folder:

`11_STACK_ONBOARDING`

Before materialization, apply the current ROTA/ROTAS taxonomy cleanup. The spec proposes:

- `TENET_ONBOARDING_DoctrinalInvariants.md`
- `ROTAS_ONBOARDING_StructuralInstantiation.md`
- `AREPO_ONBOARDING_InputAdmissibility.md`
- `OPERA_ONBOARDING_ExecutionMechanism.md`
- `SATOR_ONBOARDING_OutputRequirements.md`

Recommended normalized target shape:

- `TENET_ONBOARDING_DoctrinalInvariants.md`
- `ROTA_ONBOARDING_StructuralInstantiation.md`
- `AREPO_ONBOARDING_InputAdmissibility.md`
- `OPERA_ONBOARDING_ExecutionMechanism.md`
- `SATOR_ONBOARDING_OutputRequirements.md`

Rationale: `ROTAS` is the class. `ROTA` is an object or instance pertaining to that class. `ROTAE` is the plural for several ROTA instances. Only the class law namespace should preserve `AGLA_ROTAS_CLASS_LAW`.

## Taxonomy Review

The raw extraction preserves older conversation vocabulary. It should not be canonicalized in place unless the raw provenance layer is intentionally replaced. Instead, normalize any promoted/materialized derivative.

Observed taxonomy risks in the extracted bundle:

- `ROTAS_[X]` occurrences: 368
- `ROTAS [X]` occurrences: 257
- `ROTA_[X]` occurrences: 53
- `ROTA [X]` occurrences: 83
- `ring`: 33 matches
- `wheel`: 56 matches
- `RODA`: 0 matches
- `AGLA_ROTA_CLASS_LAW`: 2 matches
- `AGLA_ROTAS_CLASS_LAW`: 6 matches

Normalization rules for any derivative:

- Convert instance names such as `ROTAS_T`, `ROTAS T`, `ROTAS_D`, or `ROTAS D` to `ROTA_T`, `ROTA T`, `ROTA_D`, or `ROTA D` when the reference is to an object/instance.
- Keep `ROTAS` when the reference is to the class.
- Keep `AGLA_ROTAS_CLASS_LAW` as the class-law namespace.
- Treat `AGLA_ROTA_CLASS_LAW` as a legacy lookup/reference surface, not the current canonical class-law name.
- Convert `ring` to `wheel` where it names a ROTA machine substructure.
- Treat `RODA`, if it appears in future imports, as `wheel`, not as `ROTA`.
- Preserve `wheel` when it refers to W1/W2/W3 or other machine substructure; convert `wheel` to `ROTA` only when the text is actually naming the machine itself.

## Transfer Recommendation

For future migrations from ChatGPT conversations, the best source artifact is not the share link, HTML, MHTML, or PDF. Those are useful evidence layers, but they are brittle for extraction.

Recommended transfer packet:

1. Direct share link for provenance.
2. HTML export for a browser-readable local copy.
3. MHTML export for a self-contained local copy.
4. PDF export for visual fallback.
5. Explicit text bundle emitted by the source chat with filenames and hashes.

Suggested source-chat prompt:

```text
Emit an AGLA_TRANSFER_BUNDLE for repository import.

Rules:
- Do not summarize artifacts.
- Emit each artifact as exact plain text.
- Use one BEGIN_ARTIFACT / END_ARTIFACT block per file.
- Include a manifest with artifact_count, filenames, byte counts if available, and SHA-256 hashes if available.
- Mark canon status explicitly as CANDIDATE unless I say otherwise.
- Preserve provenance notes separately from canonical content.

Format:

AGLA_TRANSFER_BUNDLE
source_conversation_url: <url>
status: CANDIDATE
artifact_count: <n>

BEGIN_ARTIFACT filename="relative/path/FILE.md"
<exact file content>
END_ARTIFACT filename="relative/path/FILE.md"

BEGIN_ARTIFACT filename="relative/path/NEXT_FILE.md"
<exact file content>
END_ARTIFACT filename="relative/path/NEXT_FILE.md"

END_AGLA_TRANSFER_BUNDLE
```

This lets Codex import the transfer deterministically, verify file count and hashes, and avoid scraping packed application state.