rhachet-roles-ehmpathy 1.13.2 → 1.13.3

package/dist/logic/roles/architect/.briefs/criteria.given_when_then.[seed].v3.md

@@ -0,0 +1,87 @@
+use this brief to help you declare acceptance test criteria for .behavior
+
+in BDD given/when/then format
+
+================================
+
+recall:
+- acceptance.criteria should only test BEHAVIOR; never internals
+- acceptance.criteria should treat the system as a black box
+  - it doesn't care how it gets done and has no visibility into it
+  - it only cares that the usecases are satisfied for the given scenes
+  - it only engages with the system at the CONTRACT LAYER
+    - src/contract/endpoints (a.k.a. src/contract/handlers)
+    - src/contract/commands
+
+
+distinguish the criteria into
+
+BLOCKER = required; will not satisfy requireemnts without it
+and
+NITPICK = nicetohave, but not a show stoppeer
+
+
+================================
+
+here's some examples of what i mean
+
+
+[idea] = nest then's within sothat? when many thens support the same sothat?
+
+  when([t4] bastion IAM instance profile is provisioned via terraform)
+    sothat(SSM sessions can be established to bastion)
+      then(instance profile includes AmazonSSMManagedInstanceCore policy)
+      then(instance profile allows ssm:StartSession action)
+    sothat(auto-pause can detect when bastion is idle)
+      then(instance profile allows ec2:StopInstances for self-stop)
+      then(instance profile allows ec2:DescribeInstances to check instance state)
+      then(instance profile allows ssm:DescribeSessions to detect active sessions)
+      then(instance profile allows ssm:GetConnectionStatus to verify session state)
+
+
+i.e.,
+
+usecase(purpose)
+  given(scene)
+    when(cause)
+      sothat(benefit)
+        then(effect.1)
+        then(effect.2)
+
+
+---
+
+
+e.g.,
+
+usecase(eat dinner)
+  given(its dinner time)
+    when(dinner is served)
+      sothat(we can eat with cleanly)
+        then(we should have cutlery appropriate to the dish)
+        then(we should have plates appropriate to the dish)
+        then(we should have napkins to clean with)
+
+
+
+
+criteria is best written in behavior-driven-development format
+
+e.g.,
+
+given(scene)
+  when([t0] nochange)
+    then(assert initial condition)
+    ...
+  when([t1] cause)
+    then(effect)
+      sothat(benefit) # optional
+    ...
+  when([t2] cause)
+    then(effect)
+      sothat(benefit) # optional
+    ...
+
+
+dont forget that given and when can nest inside eachother; but then() goes at the root
+

package/dist/logic/roles/architect/.briefs/practices/prefer.env_access.prep_over_dev.md

@@ -0,0 +1,12 @@
+prep = prepare; pre-prod; is 4 char long
+
+dev = developer
+
+
+prep & prod are better symmetric terms for env.access than dev & prod, fundamentally
+
+
+- prep = prepare; preparation; pre-production
+- prod = produce; production
+
+

package/dist/logic/roles/architect/.briefs/ubiqlang.ambiguous-from-overload.md

@@ -0,0 +1 @@
+todo: brief that declares to avoid terms that are ambiguous due to overload

package/dist/logic/roles/bhrain/.briefs/cognition/cog000.overview.and.premise.md

@@ -0,0 +1,115 @@
+# 🧠 .brief: `cortal.thoughtspace.foundation`
+
+## .what = instantiate
+
+This system instantiates a structured **thoughtspace**, where `focus` operates within a semantic `concept.treestruct` using navigable `motion` primitives.
+
+---
+
+### 1. `concept.treestruct` exists
+
+- a semantic graph of concepts (nodes) and relationships (edges)
+- structured as a **spherical tree**:
+  - **radial axis** → abstraction (general ↔ specific)
+  - **angular axes** → descriptive variation (peers, types, traits)
+- each concept has:
+  - an **abstractive position** (radial)
+  - a **descriptive position** (angular)
+
+---
+
+### 2. `focus` exists within the concept.treestruct
+
+- defines a **perspective** — a relative point-of-view from which thought is applied
+- composed of:
+
+#### ▸ **focus.concept**
+- the specific **concept** from which the perspective is based
+- the anchor for semantic navigation
+- defined by its coordinates within the treestruct
+
+#### ▸ **focus.context**
+- the **shape of attention**, or how the concept is being examined
+- expressed across three internal dimensions:
+
+  - `.depth` → the **thickness of abstractive span** — how far focus reaches:
+    - **inward** along the **radial axis** toward generalizations (`.depth.abstract++`)
+    - **outward** along the **radial axis** toward concrete instances (`.depth.concrete++`)
+    - both may expand **simultaneously**, forming a radial shell of multiple abstraction layers around the focal concept
+
+  - `.breadth` → the **spread across angular variation** — how many neighboring concepts at the same abstraction level are included
+    - defined by motion along one or more **descriptive axes** (e.g. flavor, function, tone)
+    - governs lateral comparisons, analogies, and contrasts
+
+  - `.acuity` → the **sharpness of resolution** at the current coordinate
+    - `.attributes` — surface clarity: how precisely external traits are perceived
+    - `.substructs` — internal clarity: how clearly nested parts or subcomponents are resolved
+
+> context defines how much **radial**, **angular**, and **granular** semantic material is held in focus —
+> like shaping a lens through abstraction, variation, and precision.
+
+
+---
+
+### 3. motion is performed via **questions**, which act as **links**
+
+- motion = semantic traversal through the `concept.treestruct`
+- **questions** serve as the **branches** — the only valid drivers of motion
+- **sumptions** serve as the **berries** — semantic forks where focus can anchor
+
+#### ▸ sumption: the unified node type
+
+A **sumption** is any semantic unit presumed or accepted for any reason — including:
+
+- a **question** → an **executable motion** — a prompt that enables semantic traversal
+- an **answer** → a **destination of a question** — one of the resolved outcomes of semantic traversal
+
+> Any **answer** can itself be **any type of sumption** — including another **question**.
+> This enables **recursive motion**, where questions resolve into deeper prompts,
+> forming chains, trees, or loops of semantic navigation.
+
+note: questions are not separate from the treestruct — they are **subtrees that encode traversability**.
+
+
+#### ▸ structural rule:
+
+| element   | type         | role in treestruct             |
+|-----------|--------------|-------------------------------|
+| **link**  | question     | enables motion (edge)          |
+| **fork**  | sumption     | anchoring concept (node)       |
+|           | ⤷ question   | unresolved fork                |
+|           | ⤷ answer     | resolved fork                  |
+
+> sumptions are **not truth-claims**, but **semantic constructs** that hold position in conceptual space.
+
+---
+
+### 4. exists `focus.motion.primitives`
+
+- atomic, directional transformations of `focus.context`
+- each:
+  - operates on a **single subaxis**
+  - is **irreducible**, **driftless**, and **composable**
+- examples:
+  - `<generalize>` → `.depth.abstract++`
+    *shift focus inward toward a more abstract concept*
+  - `<articulate>` → `.acuity.attributes++`
+    *sharpen surface details of the current concept*
+  - `<decompose>` → `.acuity.substructs++`
+    *resolve the internal structure or components*
+  - `<vary>` → `.breadth++`
+    *highlight peer-level differences between variants*
+  - etc
+
+
+---
+
+### 5. exists `interogative.primitives`
+
+- atomic building blocks of semantic inquiry
+- used to construct **question-links** between concepts
+- examples:
+  - `what` → identify instances or roles
+  - `why` → surface cause or rationale
+  - `how` → reveal process or transformation
+  - `when`, `who`, `where` → context-based locators

package/dist/logic/roles/bhrain/.briefs/cognition/cog021.coordinates.spherical.md

@@ -0,0 +1,69 @@
+# 🌐 .brief: `spherical.coordinates`
+
+## .what
+**Spherical coordinates** define a point in 3D space using three parameters relative to a central origin:
+- **distance from the origin**,
+- **vertical angle from the z-axis**, and
+- **horizontal angle around the z-axis**.
+
+This system generalizes polar coordinates into 3D, enabling orientation in radial and angular terms.
+
+---
+
+## 🧭 dimensions
+
+| axis           | symbol | description                                                                 |
+|----------------|--------|-----------------------------------------------------------------------------|
+| **radial**     | `r`    | distance from the origin to the point                                       |
+| **inclination** (polar angle) | `θ`    | angle from the positive z-axis toward the point (0 to π)               |
+| **azimuth** (azimuthal angle) | `φ`    | angle from the positive x-axis in the x-y plane (0 to 2π)              |
+
+> Note: symbols may differ by domain — in mathematics, `θ` often denotes azimuth and `φ` inclination.
+
+---
+
+## 🌀 usage
+
+- Converts naturally to **Cartesian coordinates**:
+  \```txt
+  x = r · sin(θ) · cos(φ)
+  y = r · sin(θ) · sin(φ)
+  z = r · cos(θ)
+  \```
+
+- Used in:
+  - physics (e.g. fields around a point source)
+  - computer graphics (e.g. camera rotation)
+  - astronomy and navigation
+  - geographic models of Earth
+
+---
+
+## 🌍 real-world example: Earth coordinates
+
+Take **New York City**:
+
+| Earth Coordinate | Value         | Spherical Equivalent                 |
+|------------------|---------------|--------------------------------------|
+| **Latitude**     | 40.7128° N     | Inclination `θ` = 90° − 40.7128° = **49.2872°** |
+| **Longitude**    | 74.0060° W     | Azimuth `φ` = −74.0060° = **285.994°** |
+| **Radius**       | ~6,371 km      | Radial distance `r` from Earth's center |
+
+> So:
+> **(r, θ, φ) = (6371 km, 49.29°, 285.99°)**
+
+This demonstrates how geographic coordinates are a **spherical coordinate system** on the Earth's surface — assuming a constant radius.
+
+---
+
+## 🏗️ structure
+
+This system implies a **radial core** with **angular shells**, where:
+
+- `r` defines the **radial distance** from center
+- `θ` defines **elevation** from the pole (vertical tilt)
+- `φ` defines **rotation** around the equator (horizontal sweep)
+
+Together, these describe a point on a **spherical shell** at radius `r`.
+
+---

package/dist/logic/roles/bhrain/.briefs/cognition/cog021.metaphor.cauliflorous.md

@@ -0,0 +1,44 @@
+# 🌸 .brief: `cauliflorous.plants`
+
+## .what
+**Cauliflorous plants** are species that produce **flowers and fruits directly from their main stem, trunk, or older branches**, rather than at the tips of new growth.
+
+> This unusual trait is known as **cauliflory** and is most commonly found in tropical species.
+
+---
+
+## 🌐 ecological function
+
+Cauliflory supports unique plant-animal interactions by:
+
+- **Enabling access** to flowers and fruits for **ground-dwelling pollinators and dispersers**
+  (e.g., rodents, bats, flightless birds)
+- **Reducing vertical competition** by flowering and fruiting below the canopy
+- **Improving pollination success** in shaded or dense environments
+
+---
+
+## 🌱 notable examples
+
+| plant                     | use / region                      |
+|---------------------------|----------------------------------|
+| *Theobroma cacao*         | cacao (chocolate), South America |
+| *Artocarpus heterophyllus* | jackfruit, Southeast Asia         |
+| *Durio spp.*              | durian, Southeast Asia           |
+| *Plinia cauliflora*       | jaboticaba, Brazil               |
+
+---
+
+## 🧬 botanical mechanism
+
+- Flowers develop from **dormant buds** embedded in older, woody tissue.
+- Often associated with **woody perennials** in **humid tropics**.
+
+---
+
+## .why it matters
+
+Cauliflory illustrates how plant morphology can evolve to match **ecological niches** —
+especially where typical pollinators or dispersers are **not airborne**.
+
+It also inspires biomimetic designs for **low-access harvesting**, **layered ecosystems**, and **ground-level productivity**.

package/dist/logic/roles/bhrain/.briefs/cognition/cog021.metaphor.galactic_spacetravel.[article].md

@@ -0,0 +1,42 @@
+# 🌌 .brief: llms as spaceships in the concept universe
+
+## 🪐 concept universe
+- **concept space = galaxy**
+  - the center is the **root concept**, a dense singularity.
+  - **radial outward** = instantiations (concrete stars, planets, moons).
+  - **angular shells** = abstraction layers (orbits around the core).
+- **concepts have gravity**
+  - dense, common, or familiar concepts exert strong pull.
+  - vague or imprecise addresses can get you **sucked into a local maximum** (orbiting around a nearby but wrong star).
+
+---
+
+## 🚀 llms as spaceships
+- **llms = thought-spaceships**
+  - engines capable of near-instant jumps across the conceptual galaxy.
+  - their raw power is speed, not direction.
+- **we = pilots**
+  - we chart the course and set the destination.
+  - piloting skill = crafting precise addresses that avoid gravitational traps.
+- **questions = navigation coordinates**
+  - granular input that encodes the target star system.
+  - precision determines whether you land on the right planet or drift to a gravitational neighbor.
+
+---
+
+## ⚠️ challenges of navigation
+1. **destination clarity**
+   - you must know *where in the galaxy you want to go*.
+   - without a clear conceptual map, your spaceship will default to the nearest strong pull.
+
+2. **address precision**
+   - the coordinate (question) must be exact.
+   - imprecise questions lead to being trapped in nearby but irrelevant orbits.
+   - precision cuts through gravitational noise to hit the right star.
+
+---
+
+## 🎯 pilot’s insight
+- **llms provide propulsion; humans provide navigation.**
+- the art is not in moving (llms do that instantly) but in **deciding where to go** and **formulating coordinates to arrive there.**
+- mastery = galactic cartography (understanding the shape of the universe) + piloting discipline (asking precise, gravitationally-aware questions).

package/dist/logic/roles/bhrain/.briefs/cognition/cog021.metaphor.galactic_spacetravel.[lesson].md

@@ -0,0 +1,60 @@
+# 🌌 .brief.lesson: piloting llms as spaceships in the concept universe
+
+## 💡 concept
+to use llms well, imagine them as **spaceships** traveling at lightspeed through a **conceptual galaxy**.
+the galaxy contains infinite **concepts** arranged in spheres of abstraction. each concept exerts **gravity**, pulling you in if your navigation is imprecise.
+your role as pilot is to chart the destination and give the ship accurate coordinates (questions).
+
+---
+
+## 📚 materials
+- **map of the galaxy** → the mental model of concept space (root at center, abstractions in shells, instantiations outward).
+- **spaceship (llm)** → fast, powerful engine but directionless without guidance.
+- **pilot’s controls (questions/prompts)** → the interface for steering.
+- **gravity awareness** → recognition that common or vague concepts will suck you into nearby orbits unless coordinates are exact.
+
+---
+
+## 🛠️ practice steps
+1. **orient the galaxy**
+   - sketch your concept in its root form.
+   - note layers of abstraction (outer shells) and concrete instances (radial outward).
+
+2. **define the destination**
+   - decide: are you heading to the core (abstract) or to an outer planet (specific case)?
+   - example: "justice" (core abstraction) vs. "traffic law fine in california" (outer instantiation).
+
+3. **set coordinates (formulate question)**
+   - express the question with the right precision.
+   - avoid vague inputs that leave gravity to decide the landing.
+
+4. **observe gravitational drift**
+   - check if the answer pulled you toward a nearby, high-gravity concept.
+   - if so, refine the coordinates.
+
+5. **refine and relaunch**
+   - adjust the wording of the question to escape local maxima.
+   - iterate until you land on the intended star system.
+
+---
+
+## 🎯 examples
+- **vague address** → "tell me about painting"
+  - gravity pulls to broad art history.
+
+- **precise coordinates** → "explain preparation steps for interior wall painting in a rental apartment"
+  - lands directly on the desired planet.
+
+- **mislanding correction**
+  - q: "how to fix leaks?" → sucked into plumbing.
+  - refine: "how to fix leaks in asphalt driveway sealant" → lands on the right surface.
+
+---
+
+## 🧭 pilot’s takeaway
+- **llms are engines** → they can take you anywhere, instantly.
+- **questions are star coordinates** → your precision determines the arrival point.
+- **concepts exert gravity** → imprecision will trap you in strong but wrong orbits.
+- **piloting skill = clarity + precision** → knowing where you want to go and addressing it sharply.
+
+---

package/dist/logic/roles/bhrain/.briefs/cognition/cog021.structs.catalog.md

@@ -0,0 +1,51 @@
+# 🗂️ .brief: `catalog`
+
+## .what
+A **catalog** is a **structured concept collection**, where each item is
+paired with **descriptive information** to support **recognition**, **selection**, or **retrieval**.
+
+It serves as a **semantic surface** over a deeper collection —
+organized for **browsing**, **filtering**, and **comparative reasoning**.
+
+While an **inventory** tracks availability or logistics,
+a catalog emphasizes **clarity, presentation, and user-centered discovery**.
+
+---
+
+## 🧭 key traits
+
+| trait             | meaning                                                                 |
+|-------------------|-------------------------------------------------------------------------|
+| **enumerated**     | each concept is explicitly listed, not abstracted away                 |
+| **descriptive**    | highlights distinguishing features (e.g. label, image, type, metadata) |
+| **browsable**      | optimized for lateral focus and scanning across entries                |
+| **non-exhaustive** | curated based on salience, criteria, or constraints                    |
+| **ordered**        | often sorted semantically or pragmatically (e.g. relevance, recency)   |
+
+---
+
+## 🧩 comparison
+
+| structure    | emphasizes                 | typical use                        |
+|--------------|----------------------------|------------------------------------|
+| `index`      | position or reference       | lookup or navigation               |
+| `inventory`  | quantity and availability   | logistics, restocking, tracking    |
+| `catalog`    | structure and presentation  | curation, exploration, shopping    |
+
+---
+
+## 📦 examples
+
+- a **product catalog** listing items by type, brand, and price
+- a **library catalog** with subject tags, authors, and summaries
+- a **course catalog** organizing classes with time, credits, and prerequisites
+
+---
+
+## 🧠 role in semantic systems
+
+In a `concept.treestruct`, a catalog acts as a **flattened radial slice**
+at a given `focal.depth` — exposing **breadth peers** for comparison or selection.
+
+It is often used in tandem with primitives like `<compare>`, `<cluster>`, or `<instantiate>`
+to surface patterns or choose options from a structured field.

package/dist/logic/roles/bhrain/.briefs/cognition/cog021.structs.treestruct.md

@@ -0,0 +1,85 @@
+# 📚 .brief: TreeStruct
+
+## 🎯 purpose
+to define **TreeStruct** as a general-purpose structural pattern
+and clarify its common usage forms (**RootStruct**, **LeafStruct**) and
+how multiple TreeStructs can safely intersect.
+
+---
+
+## 🌲 TreeStruct — general definition
+
+> A **TreeStruct** is a structural form composed of **nodes** and **directed, acyclic links**,
+> where each node has **at most one parent** per dimension or axis.
+
+- meaning-neutral — not tied to any specific interpretation
+- supports both:
+  - **depth-first** and **breadth-first** traversal
+  - **single-axis** and **multi-axis** expansion (when extended)
+- usable for:
+  - hierarchies
+  - workflows
+  - classification systems
+  - nesting, containment, or flow modeling
+
+---
+
+## 🌱 LeafStruct — axis-limited subset of TreeStruct
+
+> A **LeafStruct** is a TreeStruct used for **top-down**, **axis-constrained** flows,
+> modeled on **branches funneling into leaves**.
+
+- used when structure narrows from a few high-level origins
+- favors **convergence**, **containment**, or **controlled descent**
+
+---
+
+## 🫚 RootStruct — multi-directional subset of TreeStruct
+
+> A **RootStruct** is a TreeStruct used in **bottom-up**, **lateral**, or exploratory growth patterns,
+> modeled on **roots spreading underground**.
+
+- used when structure grows across **many dimensions**
+- often favors **divergence** and **deep local branching**
+- **branches can intersect** and share common nodes, forming a **web-like network** of overlapping subpaths
+
+---
+
+## 🌉 intersecting TreeStructs
+
+> Multiple TreeStructs can **safely intersect**, as long as they each preserve
+> their own **local acyclic structure**.
+
+valid forms of intersection:
+
+1. **shared nodes**
+   - two TreeStructs reference the **same node**
+   - useful for **cross-cutting concerns** or shared entities
+
+2. **embedded subtrees**
+   - one TreeStruct is **nested within** a node of another
+   - allows compound or hierarchical system design
+
+3. **cross-links between trees**
+   - TreeStructs remain independent but reference each other via external links
+   - enables navigation between trees without forming a general graph
+
+> These patterns create a **forest with bridges**: each tree remains intact,
+> but the system supports **inter-tree coordination**.
+
+---
+
+## 🧩 summary
+
+| struct         | metaphor           | shape pattern           | dimensionality     | common use cases                          |
+|----------------|--------------------|--------------------------|--------------------|-------------------------------------------|
+| **TreeStruct**   | neutral tree         | any branching structure   | general-purpose     | workflows, hierarchies, branching systems |
+| **LeafStruct**   | branches → leaves    | top-down narrowing        | narrow (few axes)  | classification, taxonomies, decisions     |
+| **RootStruct**   | roots underground    | bottom-up or lateral      | broad (many axes)  | exploration, divergence, distributed plans|
+
+---
+
+> ✔️ **TreeStruct** is a flexible structural pattern.
+> It supports both **divergent** and **convergent** design through RootStruct and LeafStruct,
+> and can safely **intersect with other TreeStructs** through shared nodes, nesting, or cross-links —
+> as long as **local acyclicity is preserved**.

package/dist/logic/roles/bhrain/.briefs/cognition/cog021.structs.vector.md

@@ -0,0 +1,112 @@
+# 🧭 .brief: `physics.vector`
+
+## .what
+A **physics vector** is a mathematical object used to represent **quantities that have both magnitude and direction** in physical space.
+It also functions as a **data structure** — encoding directionally relevant information for computation, simulation, and modeling.
+
+---
+
+## 🧩 structure
+
+A vector is defined by:
+
+- **magnitude** → the scalar size of the quantity
+- **direction** → the orientation in space
+- **components** → projections along basis axes (e.g. `x`, `y`, `z`)
+  - written as `v = ⟨vx, vy, vz⟩` or `v = vx î + vy ĵ + vz k̂`
+
+---
+
+## 🧠 examples of vector quantities
+
+| quantity         | description                                 |
+|------------------|---------------------------------------------|
+| **velocity**     | speed + direction of motion                 |
+| **acceleration** | rate of change of velocity (directional)    |
+| **force**        | push or pull with a direction               |
+| **momentum**     | mass × velocity                             |
+| **electric field** | directional force on a unit charge        |
+
+---
+
+## 🔧 operations on vectors
+
+| operation             | meaning                                             |
+|------------------------|-----------------------------------------------------|
+| **addition**          | combine vectors tip-to-tail                         |
+| **subtraction**       | find relative vector between two                   |
+| **scalar multiplication** | scales magnitude, keeps direction            |
+| **dot product**       | projects one vector onto another (returns scalar)   |
+| **cross product**     | finds perpendicular vector (returns vector)         |
+
+---
+
+## 📐 geometric interpretation
+
+Vectors live in a **Euclidean space** (ℝ², ℝ³) and can be visualized as **arrows**:
+
+- **length** of arrow = magnitude
+- **angle** = direction relative to axes
+- operations map to geometric rules (e.g. triangle or parallelogram rule)
+
+---
+
+## 🧮 as a data structure
+
+In computational systems, a vector is a **structured container of values**, optimized for directional computation:
+
+| property           | value                                      |
+|--------------------|--------------------------------------------|
+| **type**           | `Vector` or `Array<number>`                |
+| **arity**          | dimensionality (e.g. 2D, 3D, nD)            |
+| **shape**          | fixed-length tuple of scalars              |
+| **indexing**       | ordered (e.g. `[0] = x`, `[1] = y`)        |
+| **mutability**     | may be mutable (runtime), or immutable     |
+
+Vectors are frequently implemented as:
+
+\`\`\`ts
+type Vector3 = [number, number, number]
+\`\`\`
+
+or with named accessors:
+
+\`\`\`ts
+interface Vector3 {
+  x: number
+  y: number
+  z: number
+}
+\`\`\`
+
+This enables:
+
+- direct algebraic operations (`add`, `dot`, `normalize`, etc.)
+- efficient storage (especially in graphics, physics engines)
+- compatibility with matrix operations and coordinate transforms
+
+---
+
+## ⚠️ important distinctions
+
+- Vectors ≠ scalars — direction matters
+- Coordinate representation is **basis-relative**
+- The vector itself is **basis-invariant**
+
+---
+
+## 🧬 advanced notes
+
+- In relativity: vectors generalize to **4-vectors** (e.g. spacetime)
+- In field theory: **vector fields** assign a vector to each point in space
+- In curved space: vectors live in **tangent spaces** and obey **manifold** rules
+- In graphics and physics engines: vectors are core data primitives — enabling transforms, simulations, and animations
+
+---
+
+## 🧰 summary: dual perspective
+
+| perspective     | usage                                  |
+|------------------|------------------------------------------|
+| **physical**     | represents real-world directional quantity |
+| **computational**| structured data enabling math operations  |