Polish documentation copy

packages/cli/assets/demo/orbit/wiki/global/customer-communication-policy.md

@@ -12,7 +12,7 @@ refs:
 
 ## Customer Update Communication Standard
 
-**Source:** Notion — People & Operating Norms, last edited 2026-05-07
+**Source:** Notion - People & Operating Norms, last edited 2026-05-07
 
 ---
 

packages/cli/assets/demo/orbit/wiki/global/new-hire-onboarding-policy.md

@@ -12,23 +12,23 @@ refs:
 
 ## New Hire Week-One Onboarding Policy
 
-**Source:** Notion — People & Operating Norms, last edited 2026-05-07
+**Source:** Notion - People & Operating Norms, last edited 2026-05-07
 **Owner:** Manager (not People Ops)
 
 ---
 
 ## Policy
 
-Every new hire must understand **four things by end of week one**. The manager — not People Ops — is responsible for supplying this context.
+Every new hire must understand **four things by end of week one**. The manager - not People Ops - is responsible for supplying this context.
 
 ## Required Week-One Knowledge
 
 | # | What the new hire must understand |
 |---|---|
-| 1 | **What Orbit sells** — the core procurement workflow product and value proposition |
-| 2 | **Why procurement workflow gets messy inside a customer** — the pain points that make Orbit necessary |
-| 3 | **Which team handles which part of the customer lifecycle** — team lanes and ownership boundaries |
-| 4 | **What their first useful project is** — a concrete, scoped piece of work they can contribute to immediately |
+| 1 | **What Orbit sells** - the core procurement workflow product and value proposition |
+| 2 | **Why procurement workflow gets messy inside a customer** - the pain points that make Orbit necessary |
+| 3 | **Which team handles which part of the customer lifecycle** - team lanes and ownership boundaries |
+| 4 | **What their first useful project is** - a concrete, scoped piece of work they can contribute to immediately |
 
 ## Ownership
 

packages/cli/assets/demo/orbit/wiki/global/orbit-activation-kpi-glossary.md

@@ -21,7 +21,7 @@ tables:
 # Activation KPI Glossary
 
 **Owner team:** Growth
-**Source:** Notion — Orbit Demo Home / Data Team - Onboarding / Activation KPI Glossary, last edited 2026-05-07
+**Source:** Notion - Orbit Demo Home / Data Team - Onboarding / Activation KPI Glossary, last edited 2026-05-07
 
 Use this when a question is about signup-to-habit behavior. Orbit uses activation language across Growth, Product, and CS conversations.
 
@@ -41,7 +41,7 @@ A customer is **activated** when **all three** of the following happen **within
 | 2. Email Verified | `customer.email_verified_at` is not null | `orbit_analytics.customer` |
 | 3. First Project | At least one row in `orbit_analytics.project` for the customer | `orbit_analytics.project` |
 | 4. Team Invite | At least one row in `orbit_analytics.invite` for the customer | `orbit_analytics.invite` |
-| 5. Activated | All of (2), (3), and (4) within 14 days of (1) | — |
+| 5. Activated | All of (2), (3), and (4) within 14 days of (1) | - |
 
 ## Conversion-Rate KPIs
 
@@ -51,7 +51,7 @@ A customer is **activated** when **all three** of the following happen **within
 | **D14 Activation Rate** | `activated_customers_within_14_days / signups_in_cohort` |
 | **Time-to-Activate** | `median(activated_at - created_at)` in hours |
 
-Growth conversations typically use D7 and D14 Activation Rate. Product and CS may ask about individual funnel steps — confirm whether they mean the full activation definition or only one stage.
+Growth conversations typically use D7 and D14 Activation Rate. Product and CS may ask about individual funnel steps - confirm whether they mean the full activation definition or only one stage.
 
 ## Source Notes
 

packages/cli/assets/demo/orbit/wiki/global/orbit-activation-policy-change-jan-2026.md

@@ -12,7 +12,7 @@ sl_refs:
   - mart_account_activity
 ---
 
-# Activation Policy Change — January 2026
+# Activation Policy Change - January 2026
 
 **Governed metric key:** `activated_accounts`
 **Owner team:** growth
@@ -23,8 +23,8 @@ sl_refs:
 
 The activation workflow changed on **2026-01-15**. All activation events are tagged with `policy_version`:
 
-- `pre_2026_01_15` — events before the workflow update
-- `post_2026_01_15` — events after the workflow update
+- `pre_2026_01_15` - events before the workflow update
+- `post_2026_01_15` - events after the workflow update
 
 ## Activation Event Types
 

packages/cli/assets/demo/orbit/wiki/global/orbit-arr-contract-first-definition.md

@@ -13,7 +13,7 @@ sl_refs:
   - mart_account_segments
 ---
 
-# ARR — Contract-First Definition
+# ARR - Contract-First Definition
 
 **Governed metric key:** `arr`
 **Owner team:** finance
@@ -30,10 +30,10 @@ The dbt test on `mart_arr_daily.arr_cents` asserts the value equals **1,874,200,
 
 ## Intermediate model
 
-`int_active_contract_arr` — active contract ARR as of 2026-03-31 (grain: `contract_id`).
+`int_active_contract_arr` - active contract ARR as of 2026-03-31 (grain: `contract_id`).
 
 ## Related
 
-- `stg_contracts` — contract records (status: draft, active, cancelled, expired)
-- `stg_subscriptions` — fallback ARR source (status: active, cancelled, past_due, trialing)
-- `mart_arr_daily` — board-prep daily ARR mart
+- `stg_contracts` - contract records (status: draft, active, cancelled, expired)
+- `stg_subscriptions` - fallback ARR source (status: active, cancelled, past_due, trialing)
+- `mart_arr_daily` - board-prep daily ARR mart

packages/cli/assets/demo/orbit/wiki/global/orbit-company-overview.md

@@ -15,14 +15,14 @@ refs:
 
 # Orbit Company Overview
 
-**Source:** Notion — Orbit Demo Home / Company Overview + Orbit Demo Home (root), last edited 2026-05-07
+**Source:** Notion - Orbit Demo Home / Company Overview + Orbit Demo Home (root), last edited 2026-05-07
 
 ## What Orbit Sells
 
 Orbit sells procurement workflow and spend-control software. The core value proposition: route purchase requests, collect approvals, onboard suppliers, and issue purchase orders without turning every exception into a status hunt.
 
 **Primary buyers:** Finance, Procurement, Business Operations.
-**Daily users:** department admins, office managers, IT leads, legal ops partners — anyone who has to get a vendor through the building.
+**Daily users:** department admins, office managers, IT leads, legal ops partners - anyone who has to get a vendor through the building.
 
 ## Product Workflow
 

packages/cli/assets/demo/orbit/wiki/global/orbit-customer-health-risk-definition.md

@@ -21,18 +21,18 @@ sl_refs:
 
 ## Risk Levels
 
-`low`, `medium`, `high` — derived from two signal types:
+`low`, `medium`, `high` - derived from two signal types:
 
 1. **Support ticket signals** (`stg_support_tickets`): open or pending tickets with severity `high` or `critical` increase risk.
 2. **Procurement activity signals** (`stg_purchase_requests`, `stg_purchase_orders`): recent qualifying procurement actions reduce risk.
 
 ## Intermediate Model
 
-`int_customer_health_signals` — combines open critical ticket count and recent procurement action count per account.
+`int_customer_health_signals` - combines open critical ticket count and recent procurement action count per account.
 
 ## Mart
 
-`mart_customer_health` — account-grain risk mart as of **2026-03-31**.
+`mart_customer_health` - account-grain risk mart as of **2026-03-31**.
 
 - `account_id`: dbt not_null, unique
 - `risk_level`: dbt accepted_values [low, medium, high]

packages/cli/assets/demo/orbit/wiki/global/orbit-customer-stakeholder-needs.md

@@ -13,7 +13,7 @@ refs:
 
 ## Customer Stakeholder Needs by Role
 
-**Source:** Notion — Product & Customers, last edited 2026-05-07
+**Source:** Notion - Product & Customers, last edited 2026-05-07
 
 ---
 
@@ -26,7 +26,7 @@ These are recurring, role-specific customer needs observed across accounts. Use
 | Role | Primary Need | Implication |
 |---|---|---|
 | **Finance** | Committed spend visibility earlier in the procurement cycle | Surface budget commitments at request approval, not at PO creation |
-| **Department leaders** | Request speed — faster time from request to approval | Reduce approval routing friction; minimize back-and-forth |
+| **Department leaders** | Request speed - faster time from request to approval | Reduce approval routing friction; minimize back-and-forth |
 | **Procurement** | Supplier file complete before the first invoice | Supplier onboarding must be finished before PO is issued, not after |
 | **Legal** | Fewer emergency reviews | Route contracts with legal implications earlier; avoid last-minute escalations |
 | **Customer Success (internal)** | Renewal risk visible before the account is already annoyed | CS needs leading indicators of dissatisfaction, not lagging ones |

packages/cli/assets/demo/orbit/wiki/global/orbit-customers-source.md

@@ -20,7 +20,7 @@ tables:
 
 **Table:** `orbit_analytics.customer`
 **Grain:** one row per signed-up customer
-**Source:** Notion — Orbit Demo Home / Data Team - Onboarding / Orbit Customers Source, last edited 2026-05-07
+**Source:** Notion - Orbit Demo Home / Data Team - Onboarding / Orbit Customers Source, last edited 2026-05-07
 
 Use this when a question needs customer identity, plan tier, signup timing, recent activity, or the standard customer joins.
 
@@ -29,7 +29,7 @@ Use this when a question needs customer identity, plan tier, signup timing, rece
 | Column | Type | Notes |
 |---|---|---|
 | `id` | number | Primary key, surrogate key |
-| `email` | string | Login email, unique — **do not use as join key** |
+| `email` | string | Login email, unique - **do not use as join key** |
 | `name` | string | Display name |
 | `country` | string | ISO 3166-1 alpha-2 code |
 | `plan_tier` | string | One of `free`, `pro`, `enterprise` |

packages/cli/assets/demo/orbit/wiki/global/orbit-how-we-work.md

@@ -12,7 +12,7 @@ refs:
 
 ## How We Work
 
-**Source:** Notion — Orbit Demo Home / How We Work, last edited 2026-05-07
+**Source:** Notion - Orbit Demo Home / How We Work, last edited 2026-05-07
 
 ---
 
@@ -30,7 +30,7 @@ refs:
 |---|---|
 | **Monday** | Commitments and dependency checks |
 | **Tuesday – Thursday** | Customer calls, product work, implementation, and building |
-| **Friday** | Closing loops — review what shipped, what slipped, and write down any decisions |
+| **Friday** | Closing loops - review what shipped, what slipped, and write down any decisions |
 
 Use this rhythm when scheduling work, meetings, or reviews. Do not schedule decision-making meetings on Fridays; use Friday to record decisions already made.
 
@@ -64,11 +64,11 @@ These are explicitly codified rules Orbit has identified as recurring failure mo
 - **Escalations are coordination tools, not indicators of individual failure.** Escalating is the correct behavior when a problem exceeds the current team's ability to resolve it alone.
 - When escalating, the person escalating must:
   1. Bring in the right people (those with authority or context to unblock).
-  2. Summarize current state clearly — what has been tried, what is blocked, and why.
+  2. Summarize current state clearly - what has been tried, what is blocked, and why.
   3. Name the customer impact explicitly.
   4. Keep updates moving until the risk is resolved or a workaround is established.
 - Escalations that stall because no one owns the next update are a process failure, not a customer failure.
-- An escalation is closed when the risk is resolved or a documented workaround is in place — not when the immediate noise stops.
+- An escalation is closed when the risk is resolved or a documented workaround is in place - not when the immediate noise stops.
 
 ---
 

packages/cli/assets/demo/orbit/wiki/global/orbit-known-product-gaps.md

@@ -14,7 +14,7 @@ refs:
 
 ## Known Product Gaps and Friction Points
 
-**Source:** Notion — Product & Customers (Notes from Recent Customer Calls), last edited 2026-05-07
+**Source:** Notion - Product & Customers (Notes from Recent Customer Calls), last edited 2026-05-07
 
 ---
 

packages/cli/assets/demo/orbit/wiki/global/orbit-mart-account-activity.md

@@ -33,8 +33,8 @@ tables:
 
 ## Key measures (SL: `mart_account_activity`)
 
-- `avg_pre_policy_activation_rate` — `avg(pre_policy_30_day_activation_rate)`
-- `avg_post_policy_activation_rate` — `avg(post_policy_30_day_activation_rate)`
+- `avg_pre_policy_activation_rate` - `avg(pre_policy_30_day_activation_rate)`
+- `avg_post_policy_activation_rate` - `avg(post_policy_30_day_activation_rate)`
 
 ## Common query patterns
 

packages/cli/assets/demo/orbit/wiki/global/orbit-mart-account-segments.md

@@ -37,10 +37,10 @@ tables:
 
 ## Key measures (SL: `mart_account_segments`)
 
-- `account_count` — `count(*)`
-- `total_contract_arr_cents` — `sum(contract_arr_cents)`
-- `active_contract_arr_cents` — `sum(contract_arr_cents)` where `contract_status = 'active'`
-- `active_contract_arr_millions` — active ARR in $M
+- `account_count` - `count(*)`
+- `total_contract_arr_cents` - `sum(contract_arr_cents)`
+- `active_contract_arr_cents` - `sum(contract_arr_cents)` where `contract_status = 'active'`
+- `active_contract_arr_millions` - active ARR in $M
 
 ## Common query patterns
 

packages/cli/assets/demo/orbit/wiki/global/orbit-mart-arr-daily.md

@@ -31,8 +31,8 @@ tables:
 
 ## Key measures (SL: `mart_arr_daily`)
 
-- `total_arr_cents` — `sum(arr_cents)`
-- `arr_millions` — `round(sum(arr_cents) / 100000000.0, 3)` — ARR in $M
+- `total_arr_cents` - `sum(arr_cents)`
+- `arr_millions` - `round(sum(arr_cents) / 100000000.0, 3)` - ARR in $M
 
 ## Common query patterns
 

packages/cli/assets/demo/orbit/wiki/global/orbit-mart-nrr-quarterly.md

@@ -38,8 +38,8 @@ tables:
 
 ## Key measures (SL: `mart_nrr_quarterly`)
 
-- `avg_nrr` — `avg(net_revenue_retention)` across all rows
-- `avg_nrr_enterprise` — `avg(net_revenue_retention)` filtered to `segment = 'enterprise'`
+- `avg_nrr` - `avg(net_revenue_retention)` across all rows
+- `avg_nrr_enterprise` - `avg(net_revenue_retention)` filtered to `segment = 'enterprise'`
 - `total_expansion_arr_cents`, `total_contraction_arr_cents`, `total_churned_arr_cents`
 
 ## Common query patterns

packages/cli/assets/demo/orbit/wiki/global/orbit-mart-procurement-activity.md

@@ -32,8 +32,8 @@ tables:
 
 ## Key measures (SL: `mart_procurement_activity`)
 
-- `total_active_requesters` — `sum(active_requesters)`
-- `active_requesters_200k_threshold` — `sum(active_requesters)` where `contract_arr_threshold_cents = 20000000`
+- `total_active_requesters` - `sum(active_requesters)`
+- `active_requesters_200k_threshold` - `sum(active_requesters)` where `contract_arr_threshold_cents = 20000000`
 
 ## Common query patterns
 
@@ -44,4 +44,4 @@ tables:
 
 - `active_requesters` counts non-internal, non-test requesters on large active contracts. See [orbit-procurement-qualifying-actions](orbit-procurement-qualifying-actions).
 - The standard threshold is `contract_arr_threshold_cents = 20000000` ($200k ARR).
-- Always filter by `contract_arr_threshold_cents` — the table contains rows for multiple threshold values.
+- Always filter by `contract_arr_threshold_cents` - the table contains rows for multiple threshold values.

packages/cli/assets/demo/orbit/wiki/global/orbit-mart-revenue-daily.md

@@ -36,12 +36,12 @@ tables:
 
 ## Key measures (SL: `mart_revenue_daily`)
 
-- `total_gross_revenue_cents` — `sum(gross_revenue_cents)`
-- `total_credits_cents` — `sum(credits_cents)`
-- `total_refunds_cents` — `sum(refunds_cents)`
-- `total_net_revenue_cents` — `sum(net_revenue_cents)`
-- `net_revenue_millions` — `round(sum(net_revenue_cents) / 100000000.0, 3)`
-- `gross_revenue_millions` — `round(sum(gross_revenue_cents) / 100000000.0, 3)`
+- `total_gross_revenue_cents` - `sum(gross_revenue_cents)`
+- `total_credits_cents` - `sum(credits_cents)`
+- `total_refunds_cents` - `sum(refunds_cents)`
+- `total_net_revenue_cents` - `sum(net_revenue_cents)`
+- `net_revenue_millions` - `round(sum(net_revenue_cents) / 100000000.0, 3)`
+- `gross_revenue_millions` - `round(sum(gross_revenue_cents) / 100000000.0, 3)`
 
 ## Common query patterns
 

packages/cli/assets/demo/orbit/wiki/global/orbit-metabase-sql-library-patterns.md

@@ -15,7 +15,7 @@ sl_refs:
   - mart_nrr_quarterly
 ---
 
-# Orbit Metabase SQL Library — Patterns & Conventions
+# Orbit Metabase SQL Library - Patterns & Conventions
 
 Collection **7 "SQL Library"** (parent: Orbit Showcase, collection 5) contains reference queries that demonstrate how to write Metabase native SQL against the Orbit analytics marts. Cards here are intentionally illustrative; several have `dashboardCount: 0` and are not embedded in live dashboards.
 

packages/cli/assets/demo/orbit/wiki/global/orbit-nrr-discount-expiration-treatment.md

@@ -13,7 +13,7 @@ sl_refs:
   - mart_nrr_quarterly
 ---
 
-# NRR — Discount Expiration Treatment
+# NRR - Discount Expiration Treatment
 
 **Governed metric key:** `net_revenue_retention`
 **Owner team:** analytics

packages/cli/assets/demo/orbit/wiki/global/orbit-procurement-qualifying-actions.md

@@ -12,7 +12,7 @@ sl_refs:
   - mart_procurement_activity
 ---
 
-# Procurement — Qualifying Actions & Weekly Active Requesters
+# Procurement - Qualifying Actions & Weekly Active Requesters
 
 **Governed metric key:** `weekly_active_requesters`
 **Owner team:** product

packages/cli/assets/demo/orbit/wiki/global/orbit-product-design-principles.md

@@ -13,7 +13,7 @@ refs:
 
 ## Orbit Product Design Principles
 
-**Source:** Notion — Product & Customers, last edited 2026-05-07
+**Source:** Notion - Product & Customers, last edited 2026-05-07
 
 ---
 

packages/cli/assets/demo/orbit/wiki/global/orbit-product-review-checklist.md

@@ -13,7 +13,7 @@ refs:
 
 ## Product Review Checklist
 
-**Source:** Notion — Product & Customers, last edited 2026-05-07
+**Source:** Notion - Product & Customers, last edited 2026-05-07
 
 ---
 

packages/cli/assets/demo/orbit/wiki/global/orbit-revenue-gross-to-net-reconciliation.md

@@ -12,7 +12,7 @@ sl_refs:
   - mart_revenue_daily
 ---
 
-# Revenue — Gross-to-Net Reconciliation
+# Revenue - Gross-to-Net Reconciliation
 
 **Governed metric key:** `net_revenue`
 **Owner team:** finance
@@ -25,7 +25,7 @@ sl_refs:
 net_revenue = gross_revenue - credits - refunds
 ```
 
-All amounts are in **cents** (USD only — `stg_invoices.currency` is asserted to be `USD`).
+All amounts are in **cents** (USD only - `stg_invoices.currency` is asserted to be `USD`).
 
 ## Components
 
@@ -38,12 +38,12 @@ All amounts are in **cents** (USD only — `stg_invoices.currency` is asserted t
 
 ## Intermediate model
 
-`int_revenue_components` — daily gross, credit, refund, and net revenue components.
+`int_revenue_components` - daily gross, credit, refund, and net revenue components.
 
 ## Quality Gates
 
 - `reconciliation_check` must be `true` on every row of `mart_revenue_daily`.
-- `assert_february_2026_net_revenue` — a dbt singular test covering February 2026 net revenue total.
+- `assert_february_2026_net_revenue` - a dbt singular test covering February 2026 net revenue total.
 
 ## Line Item Types (`stg_invoice_line_items`)
 

packages/cli/assets/demo/orbit/wiki/global/sales-ops-cs-handoff-process.md

@@ -14,7 +14,7 @@ refs:
 
 ## Sales Ops → Customer Success Implementation Handoff
 
-**Source:** Notion — People & Operating Norms, last edited 2026-05-07
+**Source:** Notion - People & Operating Norms, last edited 2026-05-07
 **Owner:** Sales Ops (sender), Customer Success (receiver)
 
 ---
@@ -27,7 +27,7 @@ Sales Ops must complete the handoff **before the first implementation call**. Cu
 
 | Field | Notes |
 |---|---|
-| Current plan | Starter / Growth / Enterprise — use canonical plan name |
+| Current plan | Starter / Growth / Enterprise - use canonical plan name |
 | Account segment | self_serve / commercial / enterprise (see `orbit-plan-segment-normalization`) |
 | Contract shape | Term, ARR, any discounts or custom terms |
 | Renewal contact | Named person on the customer side responsible for renewal |
@@ -38,7 +38,7 @@ Sales Ops must complete the handoff **before the first implementation call**. Cu
 
 - **Sales Ops** is responsible for populating and delivering the handoff before the first implementation call.
 - **Customer Success** is responsible for flagging missing fields to Sales Ops before the call, not during or after.
-- If a field is unknown at handoff time, Sales Ops must note it explicitly as "unknown — to be resolved by [date]" rather than leaving it blank.
+- If a field is unknown at handoff time, Sales Ops must note it explicitly as "unknown - to be resolved by [date]" rather than leaving it blank.
 
 ## Common Failure Mode
 
@@ -51,7 +51,7 @@ Handoffs that omit contract shape or renewal contact force CS to re-engage Sales
 - Enterprise accounts with parent/child account structures require extra care during handoff.
 - Small assumptions made during handoff in these accounts tend to produce large downstream problems (billing mismatches, approval routing failures, supplier onboarding gaps).
 - When the account has parent/child complexity, Sales Ops must explicitly flag it in the handoff and document the account hierarchy before the first implementation call.
-- CS should treat any undocumented parent/child relationship as a blocker — do not proceed with implementation setup until the structure is confirmed.
+- CS should treat any undocumented parent/child relationship as a blocker - do not proceed with implementation setup until the structure is confirmed.
 
 ---