update website

Author: ngmachado

website/docs/compiler/field-guide/00-welcome.md

@@ -14,7 +14,7 @@ By the end of your first day, you should be able to:
 
 You’ll learn Ora by looking at what it produces:
 
-**Tokens → AST → Typed AST → Ora MLIR → (verification & passes) → SIR**
+**Tokens → AST → Typed AST → Ora MLIR → (verification & passes) → Sensei-IR (SIR)**
 
 This ladder is your map for both development and debugging.
 

website/docs/compiler/field-guide/02-compiler-shape.md

@@ -41,10 +41,10 @@ Think of each phase as a team member with a job and a promise:
 - **Output:** verified, optimized IR; optionally SMT results  
 - **Promise:** invalid programs are rejected early; valid programs are normalized for the backend
 
-### Ora → SIR conversion
+### Ora → Sensei-IR (SIR) conversion
 - **Input:** Ora MLIR  
-- **Output:** SIR MLIR  
-- **Promise:** whatever reaches SIR is in the “legal” subset supported by the backend
+- **Output:** Sensei-IR (SIR) MLIR  
+- **Promise:** whatever reaches Sensei-IR (SIR) is in the “legal” subset supported by the backend
 
 ## 2.2 The one design choice to remember: typed AST
 
@@ -58,7 +58,7 @@ That means:
 ## 2.3 Where to stand when you’re confused
 
 If you feel lost:
-- go back to the artifact ladder (Tokens → AST → Typed AST → MLIR → SIR)
+- go back to the artifact ladder (Tokens → AST → Typed AST → MLIR → Sensei-IR (SIR))
 - run the phase you think is failing in isolation
 - inspect the artifact
 

website/docs/compiler/field-guide/04-walkthrough.md

@@ -49,7 +49,7 @@ Type resolution answers:
 - what is the type of `value + delta`? (u256)
 - is `requires(delta > 0)` valid? (a boolean constraint)
 
-This is where many important rules live, including rules around error unions and `try`.
+Many important rules live here, including rules around error unions and `try`.
 
 ## 4.5 MLIR: the program becomes explicit operations
 

website/docs/compiler/field-guide/04b-failing-walkthrough.md

@@ -65,7 +65,7 @@ Now re-run:
 - MLIR won’t be produced because the AST isn’t structurally valid.
 
 ### Conclusion (phase-local)
-✅ **This is a parser/grammar/recovery issue**.
+✅ **Parser/grammar/recovery issue**.
 
 ### Where fixes usually live
 - parser modules (`src/parser/*`)
@@ -79,7 +79,7 @@ Now re-run:
 
 ## Failure 2 — Type resolution failure (structure is fine, meaning is wrong)
 
-Here we create a program that parses cleanly, but violates a typing rule. This is the most common onboarding confusion: “It parses, why doesn’t it compile?”
+Here we create a program that parses cleanly, but violates a typing rule. Most common onboarding confusion: “It parses, why doesn’t it compile?”
 
 ### Step 1: Create a file that uses an error union
 
@@ -122,7 +122,7 @@ contract SafeMath {
 In Ora, error unions must be **unwrapped** (typically with `try`) before you can use the success value.
 
 ### Conclusion (phase-local)
-✅ **This is a typing rule issue (type resolver), not a parser issue.**
+✅ **Typing rule issue (type resolver), not a parser issue.**
 
 ### Where fixes usually live
 - type resolver rules (`src/ast/type_resolver/*`)
@@ -182,7 +182,7 @@ Now, **change the body** to include the specific feature you’re working on (or
   - or it emits an obviously incomplete/empty region for the construct
 
 ### Conclusion (phase-local)
-✅ **This is a lowering coverage issue**.
+✅ **Lowering coverage issue**.
 
 ### Where fixes usually live
 - `src/mlir/lower.zig`

website/docs/compiler/field-guide/05-core-systems.md

@@ -92,7 +92,7 @@ Key locations:
 Responsibilities:
 - verify dialect invariants
 - canonicalize/optimize
-- convert Ora → SIR as a legality boundary
+- convert Ora → Sensei-IR (SIR) as a legality boundary
 - optionally run SMT verification passes
 
 Key locations:

website/docs/compiler/field-guide/06-debugging-playbook.md

@@ -25,7 +25,7 @@ When a user reports “the compiler is broken”, you do this:
    - typed fields wrong / type errors → type resolver / semantics
    - MLIR wrong → lowering
    - verifier complains → MLIR verifier / legality / passes
-   - conversion fails → Ora → SIR patterns
+   - conversion fails → Ora → Sensei-IR (SIR) patterns
    - Z3 fails → encoder/constraints
 
 ---
@@ -65,7 +65,7 @@ When a user reports “the compiler is broken”, you do this:
 - the lowering is producing an illegal op shape, or
 - the verifier is missing/too strict for the intended feature
 
-### Symptom: Ora → SIR conversion fails
+### Symptom: Ora → Sensei-IR (SIR) conversion fails
 **Likely area:** missing conversion pattern(s)  
 **Fix style:** add a conversion pattern and a test that fails before and passes after.
 

website/docs/compiler/field-guide/07-first-compiler-pr.md

@@ -1,6 +1,6 @@
 # Your First Compiler PR (guided "safe" changes)
 
-This chapter gives you three starter PRs. Each PR is designed to be:
+This chapter gives you three starter PRs. Each PR is scoped to be:
 - small enough to finish
 - valuable even if you’re new
 - easy to review
@@ -42,7 +42,7 @@ Pick one lowering error and add:
 
 ## PR 3 — Add one missing conversion pattern (Lane B starter)
 
-**Goal:** fix a concrete “Ora → SIR conversion failed” issue.
+**Goal:** fix a concrete “Ora → Sensei-IR (SIR) conversion failed” issue.
 
 ### What to do
 1) find the illegal or unsupported op in the emitted MLIR  

website/docs/compiler/field-guide/08-advanced.md

@@ -11,11 +11,11 @@ This chapter is for when you’re adding real language features and need end-to-
 In Ora, “legal” in practice means:
 1) the Ora MLIR is structurally valid and passes dialect verification  
 2) the program survives passes/canonicalization without breaking invariants  
-3) the IR can be converted to SIR (the backend-supported subset)
+3) the IR can be converted to Sensei-IR (SIR) (the backend-supported subset)
 
 A useful mental model:
-- **Ora → SIR conversion is a hard boundary.**
-- If a feature reaches SIR, it is in a subset the backend knows how to handle.
+- **Ora → Sensei-IR (SIR) conversion is a hard boundary.**
+- If a feature reaches Sensei-IR (SIR), it is in a subset the backend knows how to handle.
 
 ## 8.2 Passes and canonicalization
 

website/docs/compiler/field-guide/appendix-a-glossary.md

@@ -1,6 +1,6 @@
 # Appendix A — Glossary
 
-**Artifact ladder** — Tokens → AST → Typed AST → MLIR → SIR.
+**Artifact ladder** — Tokens → AST → Typed AST → MLIR → Sensei-IR (SIR).
 
 **AST** — Abstract Syntax Tree. The structured representation of the program produced by the parser.
 
@@ -16,9 +16,9 @@
 
 **Dialect verification** — Structural invariants checked on IR (distinct from SMT verification).
 
-**Legality** — Whether an op/program shape is supported and convertible (in practice, whether it can be converted to SIR).
+**Legality** — Whether an op/program shape is supported and convertible (in practice, whether it can be converted to Sensei-IR (SIR)).
 
-**Ora → SIR conversion** — Lowering pass that converts Ora IR to SIR IR (backend subset).
+**Ora → Sensei-IR (SIR) conversion** — Lowering pass that converts Ora IR to Sensei-IR (SIR) IR (backend subset).
 
 **SMT verification** — Constraint solving using a solver (e.g., Z3) to validate requires/ensures/invariants.
 

website/docs/compiler/field-guide/appendix-b-codebase-map.md

@@ -1,6 +1,6 @@
 # Appendix B — Codebase Map (quick reference)
 
-This is a navigation aid. If you’re unsure where something lives, start here.
+Navigation aid. If you’re unsure where something lives, start here.
 
 ## CLI / Orchestration
 - `src/main.zig`
@@ -19,7 +19,7 @@ This is a navigation aid. If you’re unsure where something lives, start here.
 - MLIR modules: `src/mlir/*`
 - Verification: `src/mlir/verification.zig`
 - Pass pipeline: `src/mlir/pass_manager.zig`
-- Ora → SIR conversion patterns: `src/mlir/ora/lowering/OraToSIR/*`
+- Ora → Sensei-IR (SIR) conversion patterns: `src/mlir/ora/lowering/OraToSIR/*`
 
 ## SMT / Z3
 - Z3 integration: `src/z3/*` (notably `encoder.zig`)