H-6456: Update hCore (2026-05)

.cursor/rules/autonomous-work.mdc

@@ -0,0 +1,66 @@
+---
+description: Autonomous work policy - keep iterating through the TODO until done
+alwaysApply: true
+---
+# Autonomous Work Policy
+
+## Keep Working Until Done
+
+When the user says "proceed", "keep going", "continue", or similar:
+
+1. Check [TODO.md](mdc:apps/sim-core/TODO.md) for the next incomplete item NOT in the "Follow-up Required" section
+2. Plan the work, execute it, test it, commit it
+3. **Then immediately pick up the next item** — do NOT stop and ask for permission
+4. Repeat until all actionable TODO items are complete or you hit a genuine blocker
+
+## Handling Blockers: Follow-up Required Section
+
+When you encounter an item that genuinely requires user intervention:
+1. Move it to the **"Follow-up Required TODOs"** section at the bottom of TODO.md
+2. Add a note explaining what decision or input is needed
+3. **Continue working on the next actionable item** — do NOT stop
+
+## Console Errors and E2E Errors
+
+- **Fix all console errors** that appear during normal operation or E2E tests (unless deliberately caused as part of a test)
+- After each batch of fixes, check `apps/sim-core/console.log` (written by the consoleToDisk Vite plugin) for new errors
+- React warnings (unknown props, deprecated APIs) should be fixed at the source, not suppressed
+- Failed fetch calls to removed cloud APIs should be removed from code entirely
+
+## What Counts as a Blocker (move to follow-up)
+
+- A design decision with multiple valid approaches and significant trade-offs
+- A dependency upgrade that requires user input (e.g. paid API keys, license decisions)
+- A hosting/deployment platform choice
+- A change that touches code outside `apps/sim-core/` (out of scope)
+
+## What Does NOT Count as a Blocker (keep going)
+
+- The next TODO item is large — break it into sub-tasks and start
+- You finished a commit — check for the next item and continue
+- Tests pass — move on to the next phase
+- A file needs reading before editing — read it and edit it
+- A test failure you cannot diagnose after 2 attempts — move to follow-up, continue with next item
+
+## Work Loop
+
+```
+while (TODO has incomplete items outside "Follow-up Required") {
+  item = next incomplete item from TODO.md
+  plan sub-tasks
+  execute each sub-task (edit, test, fix)
+  check console.log for new errors, fix them
+  run E2E smoke tests
+  commit with descriptive message
+  update TODO.md (mark complete, move blockers to follow-up)
+}
+```
+
+## Scope Boundary
+
+Everything outside `apps/sim-core/` is out of scope. Do not modify files there.
+The `.cursor/rules/` directory is an exception (IDE config).
+
+## Commit Cadence
+
+Commit after each logical unit of work (one migration phase, one package upgrade, one feature removal). Do not accumulate uncommitted changes across phases.

.cursor/rules/commit-messages.md

@@ -0,0 +1,24 @@
+# Commit Message Guidelines
+
+Write commit messages as concise action statements.
+
+- **Primary line:** Start with a clear verb (Add, Fix, Remove, Update, Refactor) describing what was done
+- **Focus:** Capture the purpose (WHY) and the thing accomplished
+- **Details:** If needed, add a blank line followed by a bulleted list of specific actions taken
+
+## Examples
+
+```
+Fix WASM serialization producing invalid JS object shapes
+```
+
+```
+Add centralized JSON helpers for Rust-to-JS conversion
+
+- Add to_js_json and from_js_json in util.rs
+- Replace serde_wasm_bindgen with JSON path where JS expects plain objects
+```
+
+```
+Update agent state wrapper to persist custom fields correctly
+```

.cursor/rules/docs-as-source-of-truth.mdc

@@ -0,0 +1,42 @@
+---
+description: Treat strategy and architecture docs as source of truth - read before changes, update after changes
+alwaysApply: true
+---
+
+# Documentation as Source of Truth
+
+The following documents define how the project is structured, what decisions have been made, and what work is planned. **Treat them as authoritative** — read them before making changes, follow them during implementation, and update them when reality diverges.
+
+## Key Documents
+
+| Document | Purpose | Update When |
+|----------|---------|-------------|
+| [ARCHITECTURE.md](mdc:apps/sim-core/ARCHITECTURE.md) | System structure, component relationships, data flow | Adding/removing/moving modules, changing state management, altering data flow |
+| [TODO.md](mdc:apps/sim-core/TODO.md) | Technical debt, migration roadmap, dependency status | Completing a TODO item, discovering new debt, upgrading a dependency |
+| [TESTING_STRATEGY.md](mdc:apps/sim-core/TESTING_STRATEGY.md) | Test pyramid, TDD workflow, test conventions | Adding new test patterns, changing test tooling, updating commands |
+| [README.md](mdc:apps/sim-core/README.md) | Entry point, build commands, project overview | Changing build commands, adding new apps/docs, altering project structure |
+| [.cursor/rules/hash-labs.mdc](mdc:.cursor/rules/hash-labs.mdc) | AI agent conventions, error policies, build verification | Changing conventions, updating known-error lists, adding new patterns |
+
+## Before Making Changes
+
+**Study the relevant docs before starting any task.** Don't skim — actually read and internalize the sections that relate to the area you're about to touch. This applies to features, bug fixes, refactors, and migrations alike.
+
+1. **Read ARCHITECTURE.md** to understand how the affected area is structured, what depends on it, and what patterns are in use.
+2. **Read TODO.md** to check for known issues, planned work, or migration phases that overlap with your task.
+3. **Read TESTING_STRATEGY.md** to know how the change should be tested (unit vs E2E, TDD for bugs).
+4. **Read hash-labs.mdc** for conventions that apply (state management, deletion hygiene, error policies).
+5. **Follow established patterns.** If the docs describe a pattern (e.g. state management via Context, component directory structure), follow it unless you have a strong reason not to.
+6. **If you plan to deviate**, state why in the commit message or PR description.
+
+## After Making Changes
+
+1. **Update any doc that is now inaccurate.** If your change makes a statement in ARCHITECTURE.md, TODO.md, or TESTING_STRATEGY.md wrong, fix it in the same commit.
+2. **Mark completed TODO items.** If you finish something listed in TODO.md, update its status.
+3. **Add new patterns.** If you introduce a new convention or pattern, document it in the appropriate file.
+4. **Don't leave stale docs.** Outdated documentation is worse than no documentation — it actively misleads.
+
+## When to Propose vs. Apply
+
+- **Factual updates** (completed items, corrected commands, fixed file paths): apply directly.
+- **Convention changes** (new patterns, changed policies, altered workflows): propose to the user before applying.
+- **Cursor rules changes**: always propose and get approval before modifying `.cursor/rules/*.mdc`.