HALO research handoff
Audience: Camron/Kellman and the next authorized HALO agent Current evidence line: immutable 83ab4ba88a30ec33696cc900acebfa1b7fddf400 Reviewed private baseline: 7322367bfee2e9e739b4c3581870e6e5d51f4e06 Publication state: research and preparation evidence only
What HALO is
HALO is a creator-agency operating system: a 61-route CRM spanning creators, onboarding, teams, contracts, content and Drive operations, creator/staff/ referral money workflows, payment reconciliation, customs, gamification, voice, permissions and an owner dashboard. The current source is materially larger than the 2026-08-29 research snapshot.
HALO is not yet proven as a secure production authority. Browser-controlled identity, plaintext third-party credentials, destructive/bootstrap paths, unbounded reads and incomplete provider recovery keep security and authority containment ahead of feature expansion.
What the 2026-08-30 programme achieved
The programme produced current-source research and bounded private-mirror preparation. It did not merge, deploy or flip product authority.
| Area | Verified result | Boundary |
|---|---|---|
| Current research | 61 routes, 63 tables, 314 exported Convex functions, 331 terminal reads, 115 indexes, 20 domains and 17 donor candidates | Static source truth; no runtime or production qualification |
| Research corpus | 201 artifacts across 11 evidence groups, completion receipt PASS | Large/private evidence remains in the internal corpus and is referenced rather than republished |
| Route/persona model | 61 routes, 305 persona cells and 427 state cells | Static matrix complete; runtime remains 0/427 |
| Security/performance | Focused security and bounded-query candidates passed their narrow checks | Heavy typecheck/build/browser convergence remains held |
| Postgres rewrite | Public contracts, exporter, snapshot reader, caller map, cutover DAG, route map and recovery specifications were prepared and independently reviewed | currentSourceReady=false; no database, provider, credential or authority action |
| Component system | 18 base components, six families, 51 mapped routes and 10 explicitly unclassified routes | Registry preparation only; every mount remains false |
| Integration blocks | Data workbench, knowledge, gamification, money, chat adapters and shared primitives have bounded preparation receipts | No current HALO page, route, nav or workflow was replaced |
Evidence ladder
Use these labels literally:
- Current static truth — reproduced from immutable
83ab4basource. - Reviewed preparation — bounded contracts, adapters, candidates or
synthetic checks on private descendants.
- Runtime proof — not complete; the parity matrix remains 0/427 runtime.
- Production authority — not granted.
A local PASS never implies production safety, donor qualification, database readiness, provider access or authority transfer.
Main research findings
- Trust is the critical path. Presentation gates do not establish trusted
server identity or authorization. Credential and destructive-path containment must precede expanded authority.
- The back office is the differentiator. Competitors concentrate on fan
engagement; HALO's creator, content, contracts, money, reconciliation and staff workflows are the more defensible product spine.
- Scale failures are structural. The static inventory found 234 full
collections, zero pagination and 103 guaranteed-unbounded reads. Bounded queries must preserve totals, history, order and reconciliation semantics.
- Money needs liability-grade truth. Floating money, divergent statuses and
implicit defaults are not an accounting authority. Use minor units, reversible maker-checker reconciliation and explicit creator liabilities.
- Blocks are presentation, not authority. Teable/Airtable-style workbenches,
AFFiNE-style knowledge, Buzz-style chat, gamification and money components may standardize bounded surfaces; HALO retains identity and domain truth.
Relevant repositories and donors
| Source | Why it matters | Safe use |
|---|---|---|
| SISO private HALO mirror | Only authorized Git destination for this handoff | Research branch and reviewed private descendants only |
Current client source 83ab4ba | Canonical product evidence | Read-only; never push or mutate upstream |
| Twenty ↗ | Modern CRM record/timeline patterns | Exact permitted primitives or clean-room patterns; review license boundaries |
| Teable ↗ | Grid, views and data-workbench interaction | Reimplement presentation over HALO projections/commands |
| Documenso ↗ | Signing workflow and adapter reference | HALO retains contract, token and status truth |
| Plane ↗ | Project/work-item interaction patterns | Pattern donor only unless a separate authority decision exists |
| AFFiNE ↗ | Knowledge and block presentation | Bounded knowledge surface; do not inherit backend authority blindly |
| Buzz ↗ | Scoped agency conversation and agent-workflow architecture | Separate sidecar proposal; identity, pinning, signing and recovery gates remain |
| Chatwoot ↗ | Mature support/chat federation reference | Future federation only after identity and mapping gates |
| Blnk ↗ | Double-entry ledger research | Historical proof and accounting pattern; not a current integration |
| Activepieces ↗ | Automation boundary reference | Isolated workflow adapter; never business-record authority |
No donor is approved merely because it appears in this table.
Governing questions
- Is HALO an internal agency back office, a sellable creator-agency product,
or a wider fan/agency operating system?
- Which system owns each aggregate: identity, creator, team, invitation,
content/Drive, contract, money, game and provider effect?
- What proves a trusted server session, revocation and negative authorization?
- How is one complete current-source snapshot acquired without copying secrets
or creating a second authority?
- Are credentials re-enrolled or subjected to a separately authorized security
migration review?
- For every irreversible provider effect, what receipt, high-water and recovery
rule proves there is no dual dispatch or silent replay?
- Can all 61 routes, personas, states, workflows and the approved navigation
survive a change byte-for-byte where required?
- Is a proposed block merely presentation, or is it quietly taking identity,
money, approval or provider authority?
- What evidence moves a claim from static preparation to runtime proof and
then to production authority?
Current choices
| Choice | Current state |
|---|---|
| Current-source acquisition | Choose a bounded internal query only if it fits provider limits; otherwise consider a controlled backup path with separately approved custody. Neither is selected. |
| Credentials | Re-enrolment is recommended. Migration remains review-only and cannot authorize credential access. Neither is selected. |
| Sessions | Source-return versus target-retain recovery is independently prepared; neither is selected or recommended. |
| Invitations | Source-return versus forward recovery is independently prepared; forward recovery is conditional, not selected. |
| Provider effects | Twenty-row recovery boundary passed preparation review, but remains unready and un-escalated; all ten admissions are false. |
| Creator recovery | Writer and Drive seams passed preparation review; source closure, model-profile support and scheduler high-water remain prerequisites. |
| Agency chat | The current /messages webhook cannot be silently replaced. Preserve it or explicitly authorize a separate route/workflow decision. |
| Component registry | Preparation is review-ready; approval still grants no mount, runtime or rollout authority. |
Blockers
- Heavy verification is guardian-denied while swap use exceeds 4 GiB.
- Current-source acquisition and credential direction need named authorized
decisions before real data or credential work.
- Runtime parity is 0/427; browser and broad build proof were not admitted.
- Reverse readiness remains incomplete; no whole-product authority flip exists.
- No client production, provider, database, credential or deployment authority
is included in this research handoff.
Smallest next move
First answer the product question in one sentence. If the direction remains a private HALO rewrite, make only the two bounded policy choices that unlock evidence without changing authority: select the current-source acquisition mechanism for a secret-free fit proof, and select credential re-enrolment or a review-only migration design. Then run one private-mirror security/runtime gate when the storage guardian admits it. Do not start with a donor mount.
Traversal map
- Human front door:
https://halocrm-research.pages.dev/ - Machine handoff:
/data/research-handoff-manifest.json - Current research synthesis:
/docs/current-research/ - Deeper reusable/historical research:
/docs/ - Domain map:
/domains/routes and the legacy map preserved behind the
current-evidence banner
- Internal complete registry:
site/data/halo-artifact-registry.json - Internal programme truth:
build/program-manager/FLEET-STATUS.md - Internal worktree truth:
build/knowledge-spine/worktree-ledger.json
The last three internal paths are private evidence references and are not copied to the public deployment.