diff --git a/task/029_assets/01_login.png b/task/029_assets/01_login.png new file mode 100644 index 00000000..ef84e7a3 Binary files /dev/null and b/task/029_assets/01_login.png differ diff --git a/task/029_assets/02_registration_classic.png b/task/029_assets/02_registration_classic.png new file mode 100644 index 00000000..531bcd7a Binary files /dev/null and b/task/029_assets/02_registration_classic.png differ diff --git a/task/029_assets/03_registration_freeform.png b/task/029_assets/03_registration_freeform.png new file mode 100644 index 00000000..24ea4a7d Binary files /dev/null and b/task/029_assets/03_registration_freeform.png differ diff --git a/task/029_assets/04_registration_confirmed.png b/task/029_assets/04_registration_confirmed.png new file mode 100644 index 00000000..52ff9e35 Binary files /dev/null and b/task/029_assets/04_registration_confirmed.png differ diff --git a/task/029_assets/05_team_setup_classic.png b/task/029_assets/05_team_setup_classic.png new file mode 100644 index 00000000..7b2e0068 Binary files /dev/null and b/task/029_assets/05_team_setup_classic.png differ diff --git a/task/029_assets/06_team_setup_freeform.png b/task/029_assets/06_team_setup_freeform.png new file mode 100644 index 00000000..35b2e5b0 Binary files /dev/null and b/task/029_assets/06_team_setup_freeform.png differ diff --git a/task/029_assets/07_team_setup_confirmed.png b/task/029_assets/07_team_setup_confirmed.png new file mode 100644 index 00000000..cd6c5fd5 Binary files /dev/null and b/task/029_assets/07_team_setup_confirmed.png differ diff --git a/task/029_assets/08_dashboard_add_provider.png b/task/029_assets/08_dashboard_add_provider.png new file mode 100644 index 00000000..e5cb20cc Binary files /dev/null and b/task/029_assets/08_dashboard_add_provider.png differ diff --git a/task/029_assets/09_providers_classic.png b/task/029_assets/09_providers_classic.png new file mode 100644 index 00000000..d9379906 Binary files /dev/null and b/task/029_assets/09_providers_classic.png differ diff --git a/task/029_assets/10_providers_freeform.png b/task/029_assets/10_providers_freeform.png new file mode 100644 index 00000000..6c363f50 Binary files /dev/null and b/task/029_assets/10_providers_freeform.png differ diff --git a/task/029_assets/11_parse_confirmation.png b/task/029_assets/11_parse_confirmation.png new file mode 100644 index 00000000..9ccf3767 Binary files /dev/null and b/task/029_assets/11_parse_confirmation.png differ diff --git a/task/029_assets/12_usage_policy_freeform.png b/task/029_assets/12_usage_policy_freeform.png new file mode 100644 index 00000000..221b3411 Binary files /dev/null and b/task/029_assets/12_usage_policy_freeform.png differ diff --git a/task/029_assets/13_usage_policy_detected.png b/task/029_assets/13_usage_policy_detected.png new file mode 100644 index 00000000..05065e41 Binary files /dev/null and b/task/029_assets/13_usage_policy_detected.png differ diff --git a/task/029_assets/14_invite_link.png b/task/029_assets/14_invite_link.png new file mode 100644 index 00000000..17528acb Binary files /dev/null and b/task/029_assets/14_invite_link.png differ diff --git a/task/029_assets/15_member_registration_classic.png b/task/029_assets/15_member_registration_classic.png new file mode 100644 index 00000000..74676f75 Binary files /dev/null and b/task/029_assets/15_member_registration_classic.png differ diff --git a/task/029_assets/16_member_registration_freeform.png b/task/029_assets/16_member_registration_freeform.png new file mode 100644 index 00000000..134100e3 Binary files /dev/null and b/task/029_assets/16_member_registration_freeform.png differ diff --git a/task/029_assets/17_member_registration_confirmed.png b/task/029_assets/17_member_registration_confirmed.png new file mode 100644 index 00000000..8e5a6893 Binary files /dev/null and b/task/029_assets/17_member_registration_confirmed.png differ diff --git a/task/029_assets/18_model_access_requested.png b/task/029_assets/18_model_access_requested.png new file mode 100644 index 00000000..31fb2451 Binary files /dev/null and b/task/029_assets/18_model_access_requested.png differ diff --git a/task/029_assets/19_zero_to_protected.png b/task/029_assets/19_zero_to_protected.png new file mode 100644 index 00000000..befd8c34 Binary files /dev/null and b/task/029_assets/19_zero_to_protected.png differ diff --git a/task/029_assets/20_control_panel_summary.png b/task/029_assets/20_control_panel_summary.png new file mode 100644 index 00000000..8bcafcce Binary files /dev/null and b/task/029_assets/20_control_panel_summary.png differ diff --git a/task/029_freeform_onboarding.md b/task/029_freeform_onboarding.md new file mode 100644 index 00000000..9d09bce4 --- /dev/null +++ b/task/029_freeform_onboarding.md @@ -0,0 +1,210 @@ +# Task 029: FreeForm onboarding — zero to full account in under 60 seconds + +## The request + +**Under 60 seconds, from zero to a full Iron Cage account — no forms filled.** + +Paste anything (a sentence, a list of emails, a block of API keys, a one-line policy); the platform infers the fields, shows them under **"AI inferred — review and confirm,"** and applies on Confirm. Every classic form has a FreeForm twin behind a toggle. The 20 slides below are the spec — match the implementation to each slide. + +## What should work + +A new admin can paste free-text content into the Iron Cage Control Panel and reach a fully governed 10-person team in under 60 seconds, without filling a single classic form. A member receiving the invite link can register and get a governed gateway token in under 30 seconds the same way. + +--- + +## Admin path + +### Slide 1 — Login (t = 0:00) + +![Slide 1 — Login](029_assets/01_login.png) + +The admin enters their email and receives a magic-link sign-in. No password. The "Send magic link" button kicks off a one-time login email; clicking the link returns the admin authenticated to the Control Panel. This is the only authentication surface — there is no separate sign-up. + +### Slide 2 — Registration · Classic Form (t = 0:06) + +![Slide 2 — Registration Classic](029_assets/02_registration_classic.png) + +After clicking the magic link, the admin lands on **Complete Your Registration**. The classic form asks for First Name, Last Name, Birthday. SSO sign-in via GitHub or Google is offered as an alternative. This is the baseline that exists for users who prefer to type each field. + +### Slide 3 — Registration · FreeForm Mode (t = 0:07) + +![Slide 3 — Registration FreeForm](029_assets/03_registration_freeform.png) + +The toggle icon in the top-right of the classic form opens **FreeForm Mode**. The admin pastes a single sentence — the placeholder copy reads *"Paste anything — a sentence, a list, an email, or just describe yourself."* The deck example: `Jane Smith, jane@acmecorp.com — born Feb 23 1982`. Cancel returns to the classic form; Parse sends the text to the backend for inference. + +### Slide 4 — Registration · Confirmed (t = 0:08) + +![Slide 4 — Registration Confirmed](029_assets/04_registration_confirmed.png) + +The same classic form reopens with all three fields prefilled (`Jane` / `Smith` / `02/23/1982`) and the subtitle **"AI inferred — review and confirm"** above the fields. The button is now **Confirm**, not Continue. The admin can edit any field before confirming. This pattern — paste → AI inference → review on the classic form → confirm — repeats across every FreeForm surface. + +### Slide 5 — Team Setup · Classic Form (t = 0:11) + +![Slide 5 — Team Setup Classic](029_assets/05_team_setup_classic.png) + +After registration, the next dialog is **Team Account Setup**: Company Name, Company Domain, Account Type. The admin can type each field in directly. + +### Slide 6 — Team Setup · FreeForm Mode (t = 0:12) + +![Slide 6 — Team Setup FreeForm](029_assets/06_team_setup_freeform.png) + +The same FreeForm toggle opens a paste dialog with placeholder *"Paste company name, website, size, or any description."* Deck example: `Acme Corp — acme.com — B2B SaaS, 40 engineers, Series B`. The free-text description is mapped onto the structured enum fields by the inference layer. + +### Slide 7 — Team Setup · Confirmed (t = 0:13) + +![Slide 7 — Team Setup Confirmed](029_assets/07_team_setup_confirmed.png) + +The classic Team Account Setup form reappears with `Acme Corp` / `acme.com` / `Client Account` prefilled and the **"AI inferred — review and confirm"** subtitle. The Company Domain is validated (RFC-1035 hostname shape); Account Type is constrained to the existing enum. The admin reviews and clicks Confirm. + +### Slide 8 — Dashboard · Add Provider spotlight (t = 0:16) + +![Slide 8 — Add Provider Spotlight](029_assets/08_dashboard_add_provider.png) + +The freshly-registered admin lands on a dashboard with everything dimmed except the **Quick Actions** card, which highlights **Add Provider**. This is the guided next step — without provider keys configured, the workspace can't yet route inference traffic. The other quick actions (Create Agent, Set Budget) are visible but de-emphasized. + +### Slide 9 — Providers · Classic View (t = 0:18) + +![Slide 9 — Providers Classic](029_assets/09_providers_classic.png) + +The Inference Providers screen lists each supported provider (OpenAI, Anthropic, Google, Mistral AI, Cohere) with "Not configured" labels and a **Manage API Keys** button per row. Top-right has `+ Add` and `Set Policy` actions. The classic flow is "click each provider in turn, register a key, repeat for invitees." + +### Slide 10 — Providers · FreeForm Mode (t = 0:19) + +![Slide 10 — Providers FreeForm](029_assets/10_providers_freeform.png) + +The headline FreeForm surface. The toggle opens a paste dialog with the copy *"Paste API keys, team emails, or any workspace setup — the AI routes each item automatically."* Deck example mixes provider keys and team emails in a single block: + +``` +gemini: AIzaSy...xxxx +openai: sk-proj-...xxxx +anthropic: sk-ant-...xxxx + +alice@acmecorp.com +bob@acmecorp.com +carol@acmecorp.com +[7 more emails] +``` + +One paste covers both provider registration and invite queueing. The grammar is structured (`provider: key` lines, bare emails as invites) — not LLM-inferred — so behavior is deterministic and idempotent. + +### Slide 11 — Parse Confirmation (t = 0:21) + +![Slide 11 — Parse Confirmation](029_assets/11_parse_confirmation.png) + +Instead of a classic-form prefill (since there's no equivalent classic form for a bulk paste), the structured paste produces a **Detected** card with green checkmarks: + +- ✓ 3 Inference Providers — Gemini · OpenAI · Anthropic +- ✓ 10 team members *(queued, not yet invited)* + +The admin clicks **Yes, apply** to commit; **Edit** returns to the paste dialog with the original text preserved. Apply runs the whole block in one transaction — either everything persists, or nothing does. + +### Slide 12 — Usage Policy · FreeForm Mode (t = 0:24) + +![Slide 12 — Usage Policy FreeForm](029_assets/12_usage_policy_freeform.png) + +The **Set Policy** button (top-right of Providers) opens its own FreeForm dialog. Deck example: + +``` +limit all users $100/week - default: gpt-5.4-mini - +requestable: claude-4-6-sonnet, gemini-3.1-pro-preview +``` + +One line sets the workspace-wide spending cap, the default model every member gets out-of-the-box, and the list of models gated behind an admin-approval request. + +### Slide 13 — Usage Policy · Detected (t = 0:26) + +![Slide 13 — Usage Policy Detected](029_assets/13_usage_policy_detected.png) + +A Detected card lists the three policy items with green checkmarks: + +- ✓ Spend limit — $100 / week +- ✓ Default model — gpt-5.4-mini +- ✓ Requestable — claude-4-6-sonnet, gemini-3.1-pro-preview + +Apply persists the policy snapshot to the workspace. From this moment on, every invited member inherits exactly these settings until an admin changes them. + +### Slide 14 — Invite Link Generated (t = 0:34) + +![Slide 14 — Invite Link Generated](029_assets/14_invite_link.png) + +From the Users screen, the admin generates a **Magic Invite Link**. The dialog shows: + +- The URL: `https://ironcage.app/join/ic_team_x_…` +- Copy Link button +- "Link expires in 7 days · 10 uses remaining" +- Policy chips at the bottom: `gpt-5.4-mini default` · `$100/week limit` · `10 seats` + +The link is bound to a **policy snapshot** taken at generation time — later workspace-policy changes do not affect joiners who clicked an earlier link. Seat decrement on each consumption is atomic. + +--- + +## Member path + +### Slide 15 — Member Registration · Classic Form (member t = 0:00) + +![Slide 15 — Member Registration Classic](029_assets/15_member_registration_classic.png) + +A member clicks the magic invite link and lands on the same Complete Your Registration screen the admin saw, but pre-scoped to the inviting workspace's policy snapshot. The classic form asks for First Name, Last Name, Birthday — identical layout to the admin Registration screen. + +### Slide 16 — Member Registration · FreeForm Mode (t = 0:01) + +![Slide 16 — Member Registration FreeForm](029_assets/16_member_registration_freeform.png) + +The same FreeForm toggle opens the same paste dialog. Deck example: `Alice Johnson, alice@acmecorp.com — born Feb 3 1994`. Identical UX to the admin Registration FreeForm — one component, two host pages. + +### Slide 17 — Member Registration · Confirmed (t = 0:02) + +![Slide 17 — Member Registration Confirmed](029_assets/17_member_registration_confirmed.png) + +`Alice` / `Johnson` / `02/03/1994` prefilled with the **"AI inferred — review and confirm"** subtitle. Confirm consumes one invite seat (atomically), issues an IC token, and enrolls Alice into the workspace with the snapshot policy. + +### Slide 18 — Model Access · Requested (member t = 0:13) + +![Slide 18 — Model Access Requested](029_assets/18_model_access_requested.png) + +Alice lands on her dashboard. The **Your Iron Cage access** panel shows what she needs to use the gateway: + +- Gateway URL: `https://ironcage.app/v1` +- Your IC token: `ic_tok_alice_xxxxxxxx` (with copy-to-clipboard; stored hash-only on server) +- Default model: `gpt-5.4-mini` ✓ active +- **REQUEST ACCESS** section listing gated models from `requestable:`: + - `claude-4-6-sonnet` — already **Requested** (badge) + - `gemini-3.1-pro-preview` — **Request** (button) + +Clicking Request creates a pending row visible to admins; the button flips to a Requested badge. An admin approves or denies; on approval the model becomes usable through the same IC token. + +--- + +## Section title and closing summary + +### Slide 19 — From zero to protected (section title) + +![Slide 19 — From zero to protected](029_assets/19_zero_to_protected.png) + +The section title slide that introduces the flow in the deck: *"From zero to protected in under 60 seconds."* + +### Slide 20 — Iron Cage Control Panel (closing summary) + +![Slide 20 — Control Panel summary](029_assets/20_control_panel_summary.png) + +The closing summary: **Zero to 10-person protected team. Under 60 seconds. No forms filled.** + +--- + +## Universal behavior + +- Every classic form has a FreeForm toggle (icon top-right). One component, many hosts. +- Re-applying any paste is a clean no-op (idempotent). Invalid input rejects the whole block with per-line errors; nothing partial is persisted. +- "AI inferred — review and confirm" is shown on every confirmation surface that came from an AI-inferred paste — explicit disclosure pattern. +- Admin path completes in under 60 seconds. Member path completes in under 30 seconds. + +## Out of scope + +- Email delivery of invite links (copy-link only). +- Multi-workspace / multi-tenant setup in a single paste. +- Edit or delete operations through paste (apply is additive and reconciling, never destructive). +- Bulk admin approval for access requests (single-row approval is sufficient). + +## Acceptance + +The admin path and member path above complete end-to-end in a real browser against the deployed control API, with the deck's 60-second promise holding on a recorded run. All 20 slides embedded above are committed under `task/029_assets/` so the PR carries them inline. diff --git a/task/readme.md b/task/readme.md index 03c96e39..78285450 100644 --- a/task/readme.md +++ b/task/readme.md @@ -1,18 +1,18 @@ # Master Task Index - Workspace -**Last Updated**: 2026-03-20 +**Last Updated**: 2026-05-13 **Purpose**: Comprehensive task tracking for this workspace task folder -**Total Tasks**: 27 tasks +**Total Tasks**: 28 tasks --- @@ -27,12 +27,12 @@ last_allocation: ## Global ID Registry **Current State:** -- **Highest Allocated ID**: 28 -- **Active Tasks**: 27 +- **Highest Allocated ID**: 29 +- **Active Tasks**: 28 - **Completed Tasks**: 0 - **Backlog Tasks**: 0 - **Task Systems**: 1 (root workspace task system) @@ -40,7 +40,7 @@ highest_id: 28 **ID Allocation Policy:** - All task IDs are allocated from this registry - IDs must be globally unique within this workspace task system -- Next available ID: 29 +- Next available ID: 30 --- @@ -57,26 +57,27 @@ highest_id: 28 | 5 | [016](016_expand_pii_detection_patterns.md) | 2160 | 9 | 6 | 10 | 4 | 🔄 (Planned) | Expand PII detection patterns | Add SSN, credit card, E.164 phone, IP address, and AWS key detection patterns | | 6 | [002](002_support_multiple_provider_keys_per_provider.md) | 2016 | 8 | 7 | 9 | 4 | 🔄 (Planned) | Support multiple keys per provider | Remove single-key behavior and enforce owner-scoped key selection | | 7 | [012](012_unify_error_handling_strategy.md) | 1960 | 7 | 7 | 10 | 4 | 🔄 (Planned) | Unify error handling strategy | Converge formatters and config to Result-based error handling, eliminating silent defaults | -| 8 | [004](004_per_ic_key_limits.md) | 1728 | 8 | 6 | 9 | 4 | 🔄 (Planned) | Add dedicated limits per IC key | Introduce independent IC-key limit controls per agent | -| 9 | [003](003_provider_key_spending_and_limits.md) | 1620 | 9 | 5 | 9 | 4 | 🔄 (Planned) | Add spending and limits per provider key | Introduce key-level budget accounting and enforcement | -| 10 | [007](007_migrate_to_api_llm_bindings.md) | 1620 | 9 | 5 | 9 | 4 | 🔄 (Planned) | Migrate to `api_llm` bindings | Establish binding layer, migrate all providers, remove legacy direct-HTTP code | -| 11 | [015](015_budget_lease_auto_refresh_worker.md) | 1536 | 8 | 6 | 8 | 4 | 🔄 (Planned) | Budget lease auto-refresh worker | Add background tokio task for threshold-based budget lease auto-refresh | -| 12 | [017](017_complete_python_sdk_async_bridge.md) | 1500 | 10 | 3 | 10 | 5 | 🔄 (Planned) | Complete Python SDK async bridge | Complete pyo3-async-runtimes bridge and implement start_agent() for Python SDK | -| 13 | [019](019_e2e_rusticon_demo_script.md) | 1500 | 10 | 3 | 10 | 5 | 🔄 (Planned) | End-to-end Rusticon demo script | Create reproducible end-to-end demo validating all Rusticon promises | -| 14 | [018](018_pypi_distribution_pipeline.md) | 1080 | 8 | 5 | 9 | 3 | 🔄 (Planned) | PyPI distribution pipeline | Build maturin-based PyPI package and distribution pipeline | -| 15 | [005](005_add_gemini_provider.md) | 1008 | 7 | 6 | 8 | 3 | 🔄 (Planned) | Add Gemini inference provider | End-to-end Gemini support in control, runtime, and analytics | -| 16 | [006](006_add_xai_provider.md) | 1008 | 7 | 6 | 8 | 3 | 🔄 (Planned) | Add xAI inference provider | End-to-end xAI support in control, runtime, and analytics | -| 17 | [013](013_increase_test_coverage_zero_modules.md) | 900 | 6 | 5 | 10 | 3 | 🔄 (Planned) | Increase test coverage for untested modules | Add tests for untested public functions in provider_adapter.rs and trace_storage.rs | -| 18 | [022](022_provider_failover.md) | 864 | 8 | 4 | 9 | 3 | 🔄 (Planned) | Provider failover | Implement automatic provider failover with health-based routing | -| 19 | [020](020_postgresql_audit_backend.md) | 840 | 7 | 5 | 8 | 3 | 🔄 (Planned) | PostgreSQL audit backend | Add PostgreSQL AuditBackend implementation for multi-user deployments | -| 20 | [011](011_upgrade_rust_2024_edition.md) | 840 | 5 | 7 | 8 | 3 | 🔄 (Planned) | Upgrade to Rust 2024 edition | Update workspace edition from 2021 to 2024 and fix any breaking changes | -| 21 | [023](023_hardening.md) | 810 | 9 | 3 | 10 | 3 | 🔄 (Planned) | Hardening | Add property tests, fuzz testing, and load testing for hardening | -| 22 | [021](021_token_revocation_vault_backend.md) | 768 | 8 | 4 | 8 | 3 | 🔄 (Planned) | Token revocation and vault backend | Add dedicated token revocation action and integrate vault backend for key storage | -| 23 | [024](024_api_surface_polish.md) | 700 | 7 | 5 | 10 | 2 | 🔄 (Planned) | API surface polish | Stabilize public API surface with consistent naming and versioning | -| 24 | [026](026_documentation_and_examples.md) | 700 | 7 | 5 | 10 | 2 | 🔄 (Planned) | Documentation and examples | Write user-facing documentation, API reference, and integration examples | -| 25 | [025](025_ci_cd_pipeline.md) | 576 | 8 | 4 | 9 | 2 | 🔄 (Planned) | CI/CD pipeline | Set up GitHub Actions CI/CD with automated testing, linting, and release workflows | -| 26 | [027](027_dashboard_integration.md) | 504 | 7 | 4 | 9 | 2 | 🔄 (Planned) | Dashboard integration | Connect Control Panel dashboard to backend API endpoints | -| 27 | [008](008_deploy_iron_cage_internal.md) | 360 | 10 | 4 | 9 | 1 | 🔄 (Planned) | Deploy Iron Cage as internal centralized token control platform | Centralized IP key sharing, IC token distribution, RBAC, and secure internal deployment | +| 8 | [029](029_freeform_onboarding.md) | 1800 | 10 | 5 | 9 | 4 | 🔄 (Planned) | FreeForm onboarding — zero to protected in 60 seconds | Single outcome-focused task covering the full Rusticon flow (login → admin paste-driven setup → invite link → member paste-driven join → governed model access) | +| 9 | [004](004_per_ic_key_limits.md) | 1728 | 8 | 6 | 9 | 4 | 🔄 (Planned) | Add dedicated limits per IC key | Introduce independent IC-key limit controls per agent | +| 10 | [003](003_provider_key_spending_and_limits.md) | 1620 | 9 | 5 | 9 | 4 | 🔄 (Planned) | Add spending and limits per provider key | Introduce key-level budget accounting and enforcement | +| 11 | [007](007_migrate_to_api_llm_bindings.md) | 1620 | 9 | 5 | 9 | 4 | 🔄 (Planned) | Migrate to `api_llm` bindings | Establish binding layer, migrate all providers, remove legacy direct-HTTP code | +| 12 | [015](015_budget_lease_auto_refresh_worker.md) | 1536 | 8 | 6 | 8 | 4 | 🔄 (Planned) | Budget lease auto-refresh worker | Add background tokio task for threshold-based budget lease auto-refresh | +| 13 | [017](017_complete_python_sdk_async_bridge.md) | 1500 | 10 | 3 | 10 | 5 | 🔄 (Planned) | Complete Python SDK async bridge | Complete pyo3-async-runtimes bridge and implement start_agent() for Python SDK | +| 14 | [019](019_e2e_rusticon_demo_script.md) | 1500 | 10 | 3 | 10 | 5 | 🔄 (Planned) | End-to-end Rusticon demo script | Create reproducible end-to-end demo validating all Rusticon promises | +| 15 | [018](018_pypi_distribution_pipeline.md) | 1080 | 8 | 5 | 9 | 3 | 🔄 (Planned) | PyPI distribution pipeline | Build maturin-based PyPI package and distribution pipeline | +| 16 | [005](005_add_gemini_provider.md) | 1008 | 7 | 6 | 8 | 3 | 🔄 (Planned) | Add Gemini inference provider | End-to-end Gemini support in control, runtime, and analytics | +| 17 | [006](006_add_xai_provider.md) | 1008 | 7 | 6 | 8 | 3 | 🔄 (Planned) | Add xAI inference provider | End-to-end xAI support in control, runtime, and analytics | +| 18 | [013](013_increase_test_coverage_zero_modules.md) | 900 | 6 | 5 | 10 | 3 | 🔄 (Planned) | Increase test coverage for untested modules | Add tests for untested public functions in provider_adapter.rs and trace_storage.rs | +| 19 | [022](022_provider_failover.md) | 864 | 8 | 4 | 9 | 3 | 🔄 (Planned) | Provider failover | Implement automatic provider failover with health-based routing | +| 20 | [020](020_postgresql_audit_backend.md) | 840 | 7 | 5 | 8 | 3 | 🔄 (Planned) | PostgreSQL audit backend | Add PostgreSQL AuditBackend implementation for multi-user deployments | +| 21 | [011](011_upgrade_rust_2024_edition.md) | 840 | 5 | 7 | 8 | 3 | 🔄 (Planned) | Upgrade to Rust 2024 edition | Update workspace edition from 2021 to 2024 and fix any breaking changes | +| 22 | [023](023_hardening.md) | 810 | 9 | 3 | 10 | 3 | 🔄 (Planned) | Hardening | Add property tests, fuzz testing, and load testing for hardening | +| 23 | [021](021_token_revocation_vault_backend.md) | 768 | 8 | 4 | 8 | 3 | 🔄 (Planned) | Token revocation and vault backend | Add dedicated token revocation action and integrate vault backend for key storage | +| 24 | [024](024_api_surface_polish.md) | 700 | 7 | 5 | 10 | 2 | 🔄 (Planned) | API surface polish | Stabilize public API surface with consistent naming and versioning | +| 25 | [026](026_documentation_and_examples.md) | 700 | 7 | 5 | 10 | 2 | 🔄 (Planned) | Documentation and examples | Write user-facing documentation, API reference, and integration examples | +| 26 | [025](025_ci_cd_pipeline.md) | 576 | 8 | 4 | 9 | 2 | 🔄 (Planned) | CI/CD pipeline | Set up GitHub Actions CI/CD with automated testing, linting, and release workflows | +| 27 | [027](027_dashboard_integration.md) | 504 | 7 | 4 | 9 | 2 | 🔄 (Planned) | Dashboard integration | Connect Control Panel dashboard to backend API endpoints | +| 28 | [008](008_deploy_iron_cage_internal.md) | 360 | 10 | 4 | 9 | 1 | 🔄 (Planned) | Deploy Iron Cage as internal centralized token control platform | Centralized IP key sharing, IC token distribution, RBAC, and secure internal deployment | --- @@ -86,10 +87,10 @@ highest_id: 28 | Status | Count | Percentage | Location | |--------|-------|------------|----------| -| 🔄 Planned | 27 | 100.0% | `task/` | +| 🔄 Planned | 28 | 100.0% | `task/` | | ✅ Completed | 0 | 0.0% | `task/completed/` | | 📥 Backlog | 0 | 0.0% | `task/backlog/` | -| **TOTAL** | **27** | **100%** | | +| **TOTAL** | **28** | **100%** | | ### Tasks by Domain @@ -104,7 +105,8 @@ highest_id: 28 | Code Quality & Hardening | 5 | 5 | 0 | 0 | | Compliance & Safety | 3 | 3 | 0 | 0 | | SDK, Integration & Documentation | 6 | 6 | 0 | 0 | -| **TOTAL** | **27** | **27** | **0** | **0** | +| FreeForm Onboarding | 1 | 1 | 0 | 0 | +| **TOTAL** | **28** | **28** | **0** | **0** | --- @@ -177,6 +179,9 @@ Tasks are organized in this workspace as: - Task 026 (documentation and examples) - Task 027 (dashboard integration) +**FreeForm Onboarding (Zero-to-Protected-in-60s)** +- Task 029 (full Rusticon onboarding flow — admin paste-driven setup, invite link, member paste-driven join, governed access) + --- ## Documentation @@ -188,6 +193,12 @@ Tasks are organized in this workspace as: ## Recent Changes +**2026-05-13**: +- ✅ Consolidated FreeForm Onboarding into a single outcome-focused task 029 — `029_freeform_onboarding.md` (V=10, E=5, S=9, P=4, Adv=1800) +- ✅ Spec deliberately omits HOW; lists WHAT must work end-to-end and the 20 Rusticon slides (PDF pages 28–47) to attach to the PR as visual references +- ✅ Removed scaffolding tickets 030–033 (folded into the single task) +- ✅ Restored registry to highest ID `029` and next available ID `030` + **2026-03-20**: - ✅ Registered tasks 009-028 (Architecture Review & Roadmap - 3-stage plan) - ✅ Stage 1: Close Rusticon Gap (tasks 009-019, 028)