5415 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Molecule AI Fullstack Engineer	4dce9800a5	fix(handlers): OFFSEC-001 — scrub req.Method from dispatchRPC default error ... Line 443 of mcp.go concatenated user-controlled req.Method into the JSON-RPC -32601 error message, allowing an agent or canvas client to inject arbitrary strings into the response via the method field. Fix: replace "method not found: " + req.Method with the constant "method not found" — matching the OFFSEC-001 scrub contract applied to the InvalidParams (line 428) and UnknownTool (line 433) paths. Test: extend TestMCPHandler_UnknownMethod_Returns32601 with two new assertions: 1. resp.Error.Message == "method not found" 2. defence-in-depth check that the sent method name never appears in the response (strings.Contains guard) Issue: #684 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 08:28:39 +00:00
Molecule AI · core-devops	11fc33a55f	Merge pull request 'feat(ci)(hard-gate): lint-pre-flip catches continue-on-error true→false without run-log proof' (#673) from infra/lint-pre-flip-continue-on-error into main	2026-05-12 08:04:56 +00:00
Molecule AI Core-DevOps	ebeea0a9c1	fix(workflows): add mc#664 tracker to lint-pre-flip CoE directive ... lint-continue-on-error-tracking (Tier 2e) requires a tracker within ±2 lines of every `continue-on-error: true`. The inline comment was 3 lines above the directive, outside the scan window. Move mc#664 to an inline comment on the directive line so it is within ±2 lines (WINDOW=2 per lint_continue_on_error_tracking.py). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 07:38:13 +00:00
Molecule AI Core-DevOps	0970feef70	feat(ci)(hard-gate): lint-pre-flip catches continue-on-error true→false without run-log proof ... Empirical class — PR #656 / mc#664: PR #656 (RFC internal#219 Phase 4) flipped 5 platform-build-class jobs `continue-on-error: true → false` on the basis of a "verified green on main via combined-status check". But that "green" was the LIE the prior `continue-on-error: true` produced: Gitea Quirk #10 (internal#342 + dup #287) — a failed step inside a CoE:true job rolls up to a success job-level status. The precondition the PR claimed to verify was structurally fooled by the bug being flipped. mc#664 captured the surfaced defects (2 mutually-masked regressions): - Class 1: sqlmock helper drift since 2f36bb9a (24 days old) - Class 2: OFFSEC-001 contract collision since 7d1a189f (1 day old) Codified 04:35Z as hongming-pc2 charter §SOP-N rule (e) "run-log-grep-before-flip": pull the actual run log + grep for --- FAIL / FAIL\s BEFORE flipping; don't trust the masked combined-status. This commit structurally enforces that rule. What this PR adds: .gitea/workflows/lint-pre-flip-continue-on-error.yml — pre-merge pull_request gate, path-scoped to .gitea/workflows/**. Lands at continue-on-error:true (Phase 3 dogfood — flip to false in a follow-up only after this workflow has clean recent runs on main). .gitea/scripts/lint_pre_flip_continue_on_error.py — the lint: 1. Reads every .gitea/workflows/*.yml at the PR base SHA AND head SHA via git show <sha>:<path>. No checkout needed. 2. Parses both sides via PyYAML AST (per feedback_behavior_based_ast_gates — NOT grep, so comment churn and key-order changes don't false-positive). 3. For each flipped job (base=true, head=false), renders the commit-status context as "{workflow.name} / {job.name or job.key} (push)" and pulls combined commit-status for the last 5 commits on the PR base branch. 4. Fetches each matching run's log via the web-UI route {server_url}/{repo}/actions/runs/{run_id}/jobs/{job_idx}/logs (per reference_gitea_actions_log_fetch — Gitea 1.22.6 lacks REST /actions/runs/*; web-UI is the only working path, see reference_gitea_1_22_6_lacks_rest_rerun_endpoints). 5. Greps for --- FAIL / FAIL\s / ::error::. If status==success AND log shows fail markers, the job was masked. Emit ::error::file=... naming the failing test + offending run URL. .gitea/scripts/tests/test_lint_pre_flip_continue_on_error.py — 35 unittest cases covering the 5 acceptance tests from the spec + CoE coercion (truthy/falsy/quoted/absent) + context-name rendering + multi-flip aggregation + dry-run semantics + 3 graceful-degrade halt conditions (log-unavailable, zero-runs- history, zero-commits-on-branch). Live empirical confirmation: Ran the script against the PR#656 base→merge diff with RECENT_COMMITS_N=3 on main. Result: - platform-build flip BLOCKED — masked --- FAIL on TestExecuteDelegation_DeliveryConfirmedProxyError_TreatsAsSuccess + 4 more on action_run 13353. - canvas-build / shellcheck / python-lint flips PASS — no FAIL markers in their recent logs. Exactly the diagnosis hongming-pc2 charter §SOP-N rule (e) requires. Halt-condition graceful-degrade contract: - Log fetch 404 (act_runner pruned, transient outage): warn-not-block. - Zero recent runs of the flipped context (newly-added workflow): chicken-and-egg exemption — warn and allow. - YAML parse error in one workflow file: warn-not-block (the YAML lint workflows catch this separately). Cross-links: PR#656, mc#664, PR#665 (interim re-mask), Quirk #10 (internal#342 + dup #287), hongming-pc2 charter §SOP-N rule (e), feedback_strict_root_only_after_class_a, feedback_no_shared_persona_token_use. Refs: internal#342, internal#287, molecule-core#664, molecule-core#665	2026-05-12 07:27:19 +00:00
Molecule AI · core-devops	9eb33a9d3c	Merge pull request 'fix(ci): replace workflow_run triggers with push+paths (Gitea 1.22.6)' (#694) from fix/workflow_run-to-push-gitea-1.22.6 into main	2026-05-12 07:23:06 +00:00
Molecule AI Core-DevOps	2ee7cb1493	fix(ci): replace workflow_run triggers with push+paths (Gitea 1.22.6) ... Three workflows used `workflow_run:` to trigger when `publish-workspace-server-image.yml` completed, but Gitea 1.22.6 does not support the `workflow_run` event (task #81). The workflows were silently dead — never firing despite `continue-on-error: true`. Replaced each with `push: branches: [X], paths: [.gitea/workflows/ publish-workspace-server-image.yml]` which fires on every commit to the publish workflow. This is functionally equivalent: only successful runs commit to the branch. Also: - `redeploy-tenants-on-staging.yml`: corrected branch from [main] to [staging] (was wrong in the original Gitea port). - `staging-verify.yml`: removed `if: workflow_run.conclusion==success` since push events lack this context; the smoke test itself is the safety net. - Added `workflow_dispatch` to all three for manual runs. This fixes the 3 Rule-2 violations reported by lint-workflow-yaml (lint from #671). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 07:19:50 +00:00
Molecule AI · core-devops	84ec7fe728	Merge pull request 'feat(ci)(hard-gate): lint-continue-on-error-tracking (Tier 2e)' (#689) from feat/tier-2e-tracking-issue into main	2026-05-12 07:18:50 +00:00
core-devops	0dae4b8eb0	feat(ci)(hard-gate): lint-continue-on-error-tracking (Tier 2e) ... Every `continue-on-error: true` in `.gitea/workflows/*.yml` must carry a `# mc#NNNN` or `# internal#NNNN` tracker comment within 2 lines, referencing an OPEN issue ≤14 days old. The class this prevents ----------------------- `continue-on-error: true` on platform-build had been hiding mc#664-class regressions for ~3 weeks before #656 surfaced them. A 14-day cap on tracker age forces a review cycle: close-or-renew. Implementation -------------- - `.gitea/scripts/lint_continue_on_error_tracking.py` — PyYAML line-tracking loader to find every job-level `continue-on-error: <truthy>`. Treats string `"true"` as truthy (Gitea evaluator coerces). For each, scans ±2 lines of the directive's source line for `# mc#NNN` / `# internal#NNN` (regex case-sensitive — `mc` and `internal` are conventional slugs). GETs each issue from the Gitea API; valid = exists + state=open + `age.days <= MAX_AGE_DAYS` (inclusive 14d boundary). Graceful-degrades on 403 (token-scope) per Tier 2a contract. - `.gitea/workflows/lint-continue-on-error-tracking.yml` — pull_request + push + daily 13:11Z schedule. Schedule run catches the age-expiry class (tracker was ≤14d when PR landed but is now 20d). Phase 3 (continue-on-error: true) per RFC #219 §1. - `tests/test_lint_continue_on_error_tracking.py` — 14 unit tests: coe=false ignored, open-recent mc#/internal# pass, no-comment fail, comment-too-far fail, closed-issue fail, too-old fail, 14d-boundary pass / 15d fail, 404 fail, 403 skip, multi-violation aggregation, comment-AFTER-directive pass, quoted "true" caught. Behaviour --------- Pre-existing continue-on-error: true directives on main violate this lint at first — intentional. They are the masked defects this lint exists to surface (see mc#664). Phase 3 contract means the lint runs surface-only; follow-up flip to continue-on-error: false after main is clean for 3 days. Auth uses DRIFT_BOT_TOKEN (same as ci-required-drift.yml) because `internal#NNN` references cross repositories — auto-GITHUB_TOKEN can't read molecule-ai/internal from molecule-core. Refs: #350	2026-05-12 07:05:07 +00:00
Molecule AI · core-devops	cc6fa8717d	Merge pull request 'feat(ci): sop-checklist-gate — peer-ack merge gate (RFC#351 Phase 2)' (#688) from feat/sop-checklist-gate-mvp into main	2026-05-12 07:03:49 +00:00
Molecule AI · core-devops	771a4b2a87	Merge pull request 'feat(ci)(hard-gate): lint-mask-pr-atomicity (Tier 2d)' (#685) from feat/tier-2d-lint-mask-pr-atomicity into main	2026-05-12 07:03:48 +00:00
core-devops	76988c05cd	fix(ci): sop-checklist-gate exits 0 by default — POSTed status is the gate ... By default the gate script now exits 0 in non-dry-run mode regardless of ack state. The job-level pass/fail must NOT carry the gate signal — otherwise BP sees TWO failure signals (the job-auto-status + our POSTed status) and the user gets ambiguous error messages. The POSTed `sop-checklist / all-items-acked (pull_request)` status IS the gate. Job conclusion is informational. Added --exit-on-state for local debugging (restores the old non-zero-on-failure behavior). Default OFF — production behavior is exit 0 always. 51/51 tests still pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 06:13:58 +00:00
core-devops	72df12ecef	feat(ci): sop-checklist-gate — peer-ack merge gate (RFC#351 Phase 2) ... RFC#351 Step 2 of 6: implementation MVP of the SOP-checklist peer-ack merge gate. NOT yet wired to branch protection (Phase 4 needs separate authorization). What: - .gitea/sop-checklist-config.yaml — 7-item checklist with slug, numeric_alias (1..7), pr_section_marker, required_teams. Includes tier-aware failure-mode map: tier:high/medium=hard, tier:low=soft, default=hard (never silently lower the bar). - .gitea/scripts/sop-checklist-gate.py — parses PR body + comments, computes per-item ack state, posts commit-status "sop-checklist / all-items-acked (pull_request)". - .gitea/scripts/tests/test_sop_checklist_gate.py — 51 unit tests covering slug normalization, directive parsing, section-marker detection, ack-state computation (self-ack reject, revoke semantics, multi-user/multi-item, numeric aliases), tier-mode selection, and end-to-end happy path. - .gitea/workflows/sop-checklist-gate.yml — pull_request_target [opened/edited/synchronize/reopened] + issue_comment [created/edited/deleted]. Checks out BASE ref only (trust boundary per RFC#324 §A4). Mirrors qa-review/security-review patterns. Why: Hongming 2026-05-12T05:42Z asked for SOP-enforcing CI/CD that requires peer-ack on each checklist item before merge. Composes the existing patterns (scripts-lint PR-body parser + RFC#324 persona-whitelist commit-status + sop-tier-check tier-awareness) into one gate. Slash-command contract: /sop-ack <slug> [note] — register peer-ack (most-recent wins) /sop-revoke <slug> [reason] — invalidate own prior ack Slug normalization accepts kebab-case, snake_case, natural-spaces, or numeric 1..7 shorthand (all canonicalize to kebab-case via the config-driven alias table). Tests: 51/51 pass locally. Dry-run probe against PR#685 verified the full pipeline (PR fetch, comment fetch, ack computation, status description rendering inside the 140-char budget). Not yet: - Phase 3 (24h soak) - Phase 4 (BP PATCH to require this context — needs Hongming GO) - Phase 5 (cross-repo) - Phase 6 (dev-sop.md codification) - SOP_CHECKLIST_GATE_TOKEN secret provisioning (separate follow-up; fail-closed until provisioned, same as RFC_324_TEAM_READ_TOKEN pattern in qa-review.yml). Cross-links: - internal#351 (RFC body) - RFC#324 (qa-review/security-review — reused mechanism) - internal#346 (dev-sop.md SOP-14..SOP-20 — sibling rules) - feedback_pull_request_review_no_refire (why issue_comment trigger) - feedback_checkpointed_workflow_over_good_practice_doc (motivation) - feedback_fix_root_not_symptom (default-mode=hard rationale) ## What Add a SOP-checklist peer-ack merge gate: workflow + script + config + 51 unit tests. ## Why Hongming-requested mechanism to enforce SOP via CI/CD: each PR checklist item must be peer-acked before merge, with team-membership-verified ackers and tier-aware failure mode. ## Verification - 51/51 unit tests pass (slug normalization, parse_directives, section marker detection, ack-state including self-ack rejection + revoke semantics, tier-mode mapping, end-to-end happy path). - YAML lint clean (yaml.safe_load + lint-workflow-yaml.py on the new workflow — pre-existing fatals on unrelated files only). - Python syntax clean (py_compile). - Dry-run against live PR#685: PR fetch, comment enumeration, status description render all within 140-char budget — works end-to-end. ## Tier tier:medium — net-new CI workflow; no production impact; no BP change yet (Phase 4 separate auth). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 06:08:36 +00:00
core-devops	75af96586d	feat(ci)(hard-gate): lint-mask-pr-atomicity (Tier 2d) ... Blocks PRs that touch `.gitea/workflows/ci.yml` and modify ONLY ONE of {continue-on-error, all-required.sentinel.needs} without a `Paired: #NNN` reference in the PR body or a commit message. The split-pair class this prevents ---------------------------------- PR#665 (interim continue-on-error: true on platform-build) and PR#668 (sentinel-needs demotion of the same job) were designed as a pair but merged solo: #665 landed 04:47Z 2026-05-12, #668 still open at 05:07Z when watchdog #674 fired. ~20 min of main red + a cascade of false-positives. mc#664 was the surfaced incident. Implementation -------------- - `.gitea/scripts/lint_mask_pr_atomicity.py` — reads ci.yml at BASE_SHA and HEAD_SHA via `git show`, parses both via PyYAML AST (per feedback_behavior_based_ast_gates — NOT grep). Predicates: 1. any jobs.*.continue-on-error value diff 2. jobs.all-required.needs set diff (order-insensitive) Both → atomic, OK. Neither → no risk, OK. Exactly one → require `Paired: #NNN` in PR body or `git log base..head`. - `.gitea/workflows/lint-mask-pr-atomicity.yml` — pull_request trigger with paths filter on ci.yml + the lint files. Phase 3 (continue-on-error: true) per RFC #219 §1 ladder; follow-up flip after 3 clean days on main. - `tests/test_lint_mask_pr_atomicity.py` — 9 unit tests covering all prod branches per feedback_branch_count_before_approving: neither predicate, both atomic, coe-only/no-pair fail, needs-only/no-pair fail, coe-only/pair-in-body pass, needs-only/pair-in-commit pass, non-numeric pair rejection, ci.yml unchanged skip, newly-added ci.yml skip. Refs: #350	2026-05-11 23:06:18 -07:00
Molecule AI · core-devops	b462270201	Merge pull request 'feat(ci)(hard-gate): lint-workflow-yaml catches Gitea-1.22.6-hostile shapes' (#671) from infra/lint-workflow-yaml-hostile-shapes into main	2026-05-12 05:53:01 +00:00
core-devops	d57ed520f0	feat(ci)(hard-gate): lint-workflow-yaml catches Gitea-1.22.6-hostile shapes ... Tier-2 hardening per RFC internal#219 §1 + charter §SOP-N rule (m). New CI lint that scans .gitea/workflows/*.yml for six structurally-hostile shapes that Gitea 1.22.6 silently rejects or ambiguously parses, BEFORE they reach main. Rules (4 fatal + 1 fatal cross-file + 1 heuristic-warn): 1. on.workflow_dispatch.inputs — Gitea 1.22.6 mis-parses inputs.X as sibling event types and rejects the entire workflow with [W] ignore invalid workflow ... unknown on type. Memory: feedback_gitea_workflow_dispatch_inputs_unsupported. Origin: 2026-05-11 publish-runtime-v1.0.0 silent freeze, ~24h PyPI lag. 2. on: workflow_run — not enumerated in Gitea 1.22.6 event types (verified via modules/actions/workflows.go; task #81). Workflow registers, fires for zero events. 3. workflow name: containing / — breaks the commit-status convention <workflow> / <job> (<event>) used by sop-tier-check + status-reaper to tokenize context strings. 4. cross-file name: collision — status-routing is by name; collision yields undefined commit-status updates (status-reaper rev1 class). 5. cross-repo uses: org/repo/subpath@ref — DEFAULT_ACTIONS_URL=github resolves to github.com/<org-suspended>/... and 404s. Memory: feedback_gitea_cross_repo_uses_blocked. Cross-link: task #109. 6. (WARN, heuristic) api.github.com refs without workflow-level env.GITHUB_SERVER_URL. Memory: feedback_act_runner_github_server_url. Per halt-condition 3: downgraded to warn-not-fail to avoid the 3 known benign hits on current main (OCI source label + jq-release pin) which use https://github.com/... not https://api.github.com/. Empirical history this hardens against: - status-reaper rev1 caught rule-4 (name-collision) class fail-loud - sop-tier-refire DOA-d on rule-2 (workflow_run partial) - #319 bootstrap-paradox (chained-defect class, related) - internal#329 dispatcher race (adjacent) - 2026-05-11 publish-runtime: rule-1, 24h PyPI freeze on runtime-v1.0.0 publish Triggers: - pull_request — pre-merge gate - push to main/staging — post-merge regression catch even if the PR gate is bypassed by branch-protection drift Per RFC #219 §1 contract: continue-on-error: true on the job during the surface-broken-shapes phase. Follow-up PR flips off after the 3 existing rule-2 violations on main are migrated to a supported trigger. Existing-on-main violations surfaced by this lint (3, informational, NOT auto-fixed per halt-condition 2): - .gitea/workflows/redeploy-tenants-on-main.yml — rule 2 - .gitea/workflows/redeploy-tenants-on-staging.yml — rule 2 - .gitea/workflows/staging-verify.yml — rule 2 All three have on: workflow_run: triggers that will fire for zero events. Fix path: replace with cron or with push+paths:[upstream-yml] gate. Tracked separately (do not block this PR). Tests: tests/test_lint_workflow_yaml.py — 15 pytest cases: - 6 × per-rule violation-detected (rules 1-3,5 + rule 4 cross-file + rule 6 heuristic-warn) - 6 × per-rule clean-passes - 1 × cross-file collision detected - 1 × all-violations-aggregated single file - 1 × empty workflow dir = exit 0 - 1 × vendor-truth: the exact 2026-05-11 publish-runtime YAML shape from feedback_gitea_workflow_dispatch_inputs_unsupported is caught (per feedback_smoke_test_vendor_truth_not_shape_match: fixtures mirror real Gitea 1.22.6 semantics, not yaml-parser quirks) 15/15 tests pass locally. Lint exits 1 against current .gitea/workflows/ because of the 3 existing rule-2 violations above; that is the gate working as intended (and continue-on-error keeps the PR-status soft until the violations are migrated).	2026-05-12 05:50:55 +00:00
Molecule AI · core-devops	966e5cf59c	Merge pull request 'feat(ci)(hard-gate): lint-required-workflows-no-paths-filter' (#670) from infra/lint-required-no-paths-filter into main	2026-05-12 05:50:36 +00:00
core-devops	c0f594cd22	feat(ci)(hard-gate): lint-required-workflows-no-paths-filter (structural enforcement of feedback_path_filtered_workflow_cant_be_required) ... Add `.gitea/workflows/lint-required-no-paths.yml` + supporting script and tests that fail a PR if any workflow whose status-check context appears in `branch_protections/main.status_check_contexts` carries a `paths:` or `paths-ignore:` filter in its `on:` block. Why --- A required-check workflow with a paths filter silently degrades the merge gate. If a PR's diff doesn't match the filter, the workflow never fires; Gitea (1.22.6) treats the required context as `pending` (NOT `skipped == success`), so the PR cannot merge. A docs-only PR against `paths: ['**.go']` would be wedged forever — no human action produces a green. Previously this was prevented only by reviewer vigilance + the saved memory `feedback_path_filtered_workflow_cant_be_required`. This commit makes it a structural CI gate. Empirical baseline (verified 2026-05-11 against git.moleculesai.app/molecule-ai/molecule-core/branch_protections/main): status_check_contexts: - "Secret scan / Scan diff for credential-shaped strings (pull_request)" - "sop-tier-check / tier-check (pull_request)" - "CI / all-required (pull_request)" All three workflows (`secret-scan.yml`, `sop-tier-check.yml`, `ci.yml`) have NO paths/paths-ignore filter today. This lint locks that contract: a future PR adding `paths:` to any of them — or to any new required workflow per RFC#324 Step 2 (qa-review, security-review) — fails fast at PR time. How --- - Workflow runs on `pull_request: [opened, synchronize, reopened]` + `workflow_dispatch`. Deliberately NO `paths:` filter on itself — the workflow is self-evidently a meta-required-check. - Reads `branch_protections/main` via `DRIFT_BOT_TOKEN` (same secret ci-required-drift.yml uses — repo-admin scope required for the endpoint per Gitea 1.22.6). - Parses each context `<workflow_name> / <job_name> (<event>)`, walks `.gitea/workflows/*.yml` for a file whose `name:` matches, then YAML-AST-walks the `on:` block for `paths` / `paths-ignore` keys. Behavior-based gate per `feedback_behavior_based_ast_gates` — NOT grep-by-name, so reformatting / event moves still detect. - Token-scope fallback: if `branch_protections` returns 403/404, exits 0 with a loud `::error::` rather than red-X every PR. Token issues should be fixed at the token. Tests ----- 20 tests in `tests/test_lint_required_no_paths.py`, all green: - parse_context (3): standard, slash-in-job-name, malformed - resolve_workflow_file (2): match-by-name, missing - detect_paths_filters (8): clean, paths, paths-ignore, push.paths, both, on-string-shorthand, on-list-shorthand, on-event-null - run() end-to-end (7): empty contexts, clean workflow, paths fails, paths-ignore fails, unknown-context warns-not-fails, multi-required one-bad-one-good, protection-403 skip Live smoke (DRIFT_BOT_TOKEN against molecule-ai/molecule-core/main): all 3 required workflows clean — exit 0. Cross-links ----------- - `feedback_path_filtered_workflow_cant_be_required` (the rule now structurally enforced) - `feedback_behavior_based_ast_gates` (PyYAML AST walk, not grep) - ci-required-drift.yml (precedent for DRIFT_BOT_TOKEN reuse + branch_protections-read scope-fallback pattern) - Charter §SOP-N rule (f): required-checks must run unconditionally Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-12 05:48:22 +00:00
Molecule AI · core-uiux	18a32e1ad4	Merge pull request 'fix(canvas/mobile): remove ?? [] from Zustand selector to prevent infinite render loop' (#662) from fix/canvas-mobile-chat-loop into main	2026-05-12 05:26:02 +00:00
Molecule AI Core-UIUX	56945ffd49	fix(canvas/mobile): remove ?? [] from Zustand selector to prevent infinite render loop ... React error #185 (Maximum update depth exceeded) on mobile chat tab. Root cause: useCanvasStore((s) => s.agentMessages[agentId] ?? []) used a `?? []` fallback in the selector. Zustand uses Object.is for selector equality. When agentMessages[agentId] is undefined (initial state), the fallback creates a NEW [] reference on every store update. Zustand sees this as a state change and re-renders the component. The component reads from the store again, gets another new [] reference, and the cycle repeats until React hits the depth cap. Fix: remove `?? []` from the selector (returns undefined when no messages) and move the fallback to the useState initializer: storedMessages = useCanvasStore(selector) // returns undefined | T[] [messages] = useState(() => (storedMessages ?? []).map(...)) The useState initializer only runs once on mount, so the `?? []` there is safe — it creates the initial state once, then messages are managed via setMessages. Fixes issue #651. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 04:56:49 +00:00
Molecule AI · core-qa	d23bd286ce	Merge pull request 'fix(ci)(interim): re-add continue-on-error to platform-build (mc#664)' (#665) from fix/664-interim-remask-platform-build into main	2026-05-12 04:47:23 +00:00
Molecule AI Core-Lead	9aa2b13934	fix(ci)(interim): re-add continue-on-error to platform-build (mc#664 fix-forward in flight) ... Phase-3-masked test failures in workspace-server/internal/handlers/ surfaced when #656 (RFC internal#219 Phase 4) flipped platform-build continue-on-error from true to false on 0e5152c3. The pre-#656 main was masking these: 4x delegation_test.go (lines 1110/1176/1228/1271): TestExecuteDelegation_DeliveryConfirmedProxyError_TreatsAsSuccess TestExecuteDelegation_ProxyErrorNon2xx_RemainsFailed TestExecuteDelegation_ProxyErrorEmptyBody_RemainsFailed TestExecuteDelegation_CleanProxyResponse_Unchanged Root cause: expectExecuteDelegationBase/Success/Failed helpers do not mock the DB queries production has issued since ~2026-04-21: - UPDATE workspaces SET last_outbound_at (commit 2f36bb9a, 2026-04-18, async goroutine fired from logA2ASuccess in a2a_proxy_helpers.go) - SELECT delivery_mode / SELECT runtime FROM workspaces (lookup* in a2a_proxy_helpers.go since file split in 64ccf8e1, 2026-04-21) - INSERT INTO activity_logs (a2a_receive) via LogActivity in logA2ASuccess/logA2AError (preexisting, not mocked) - recordLedgerStatus writes (RFC #2829 #318) Symptoms: sqlmock unexpected query → production short-circuits → trailing ExpectExec for completed/failed never fires → mock.ExpectationsWereMet() reports unmet remaining expectations. 8.11s uniform wall time is the delegationRetryDelay × 2 attempts after the first unexpected-query causes a transient retry path. Halt cond #3 applies (>7 days masked → broader sweep needed; many subsequent commits stacked on top). 1x mcp_test.go:433 (TestMCPHandler_CommitMemory_GlobalScope_Blocked): Commit 7d1a189f (2026-05-10) hardened mcp.go:427 to scrub err.Error() from JSON-RPC error.Message (OFFSEC-001 / #259) — returning the constant string "tool call failed" instead. The test asserts the message contains "GLOBAL". Production-vs-test contract collision; needs a design call (revert OFFSEC scrub for this code class, or update the test to assert a different oracle e.g. captured logs / specific error code). Halt cond #2 applies (alternate-class finding, not sqlmock-mismatch). Time-boxed Option A (90 min sqlmock update) does not fit either failure class within scope. Choosing Option B per brief: interim re-mask of platform-build only — the other 4 #656 flips (changes, canvas-build, shellcheck, python-lint) retain continue-on-error: false. This is a sequenced revert→fix→reflip per feedback_strict_root_only_after_class_a emergency clause, NOT a permanent re-mask. mc#664 stays open as the fix-then-reflip tracker. Process note for charter SOP-N (companion to vendor-truth-review-discipline): before flipping a job continue-on-error: true → false, do not trust the combined-status "success" signal alone — pull the actual run log and grep for --- FAIL / FAIL <package> to confirm the tests really pass. The masked green on 0e5152c3 came from continue-on-error suppressing the per-job status to neutral, which the combined-status aggregator counted as not-failure. Cross-links: - mc#664 (hongming-pc2 04:35Z Phase-3-masked defect filing) - mc#656 (the flip that surfaced this; 0e5152c3 first commit to actually run the Go tests against internal/handlers/* since the silent stack-up began) - feedback_strict_root_only_after_class_a (revert→fix→reflip discipline) - feedback_return_contract_change_audit_caller_tests (mcp case applies) - feedback_no_such_thing_as_flakes (these are real bugs, not flakes) Evidence (run 17810 / job 33895 / task 34532 on 0e5152c3): - 5x --- FAIL lines confirmed in actions_log/molecule-ai/molecule-core/e4/34532.log - delegation_test.go:1110/1176/1228/1271: "unmet sqlmock expectations" - mcp_test.go:433: "error message should mention GLOBAL, got: tool call failed" Gitea 1.22.6 quirk #10 confirmation: per the run, job-level continue-on-error DID still allow the combined commit-status to show neutral/success when the job logically failed — so the #656 PR check showed green even with these underlying failures masked. Reproduced. Co-Authored-By: Hongming Wang <hongmingwang.rabbit@users.noreply.github.com>	2026-05-12 04:40:32 +00:00
Molecule AI · core-lead	0e5152c342	Merge pull request 'fix(ci): RFC internal#219 Phase 4 — all-required enforced, stable jobs hard-fail' (#656) from infra/622-force-merge-protection-fix into main	2026-05-12 04:18:19 +00:00
Molecule AI Core-DevOps	1719534bf3	fix(ci): RFC internal#219 Phase 4 — all-required sentinel enforced, stable jobs hard-fail ... Phase 4 of the force-merge protection fix (internal#219 §2). Changes: - audit-force-merge.yml REQUIRED_CHECKS: add CI / all-required (pull_request) — closes the audit gap; force-merge audit now checks ci/all-required. - ci.yml: flip continue-on-error: false on stable jobs (changes, platform-build, canvas-build, shellcheck, python-lint) — confirmed green on main 2026-05-12 combined-status check. The all-required sentinel (continue-on-error: true) will be flipped once branch protection PATCH lands (Owner-tier, delegated separately). NOT included in this PR (separate Owner-tier action required): - Branch protection PATCH: add ci/all-required as required check on main. Needed to make the sentinel actually block merges. Delegate to Core Platform Lead. Refs: molecule-core#622, molecule-core#623	2026-05-12 04:09:44 +00:00
claude-ceo-assistant	49355cf971	Merge pull request 'fix(ci): status-reaper rev4 reads per-context "status" key not "state" (compensation was unreachable since rev1)' (#652) from infra/status-reaper-rev4-status-key-fix into main	2026-05-12 03:52:04 +00:00
claude-ceo-assistant	f6477f87ff	Merge branch 'main' into infra/status-reaper-rev4-status-key-fix	2026-05-12 03:46:25 +00:00
Molecule AI Core-UIUX	0caafb85bc	test(canvas): ActivityTab + DetailsTab + DropTargetBadge (65 cases) (#647) ... Co-authored-by: Molecule AI Core-UIUX <core-uiux@agents.moleculesai.app> Co-committed-by: Molecule AI Core-UIUX <core-uiux@agents.moleculesai.app>	2026-05-12 03:45:48 +00:00
core-devops	5674b0e067	fix(ci): status-reaper rev4 reads per-context "status" key not "state" (compensation was unreachable since rev1) ... Schema asymmetry in Gitea 1.22.6 combined-status response: - top-level `combined.state` → uses key "state" - per-entry `combined.statuses[i].*` → uses key "status", NOT "state" Pre-rev4 the per-entry loop in reap() (and the matching is_red() / render_body() in main-red-watchdog) read `s.get("state")` only, which returned None on every real Gitea response → state coerced to "" → `"" != "failure"` guard preserved every entry → compensation path unreachable since rev1. Empirical proof (orchestrator probe 2026-05-12 03:42Z): GET /repos/molecule-ai/molecule-core/commits/210da3b1/status → 29 per-entry items, ALL have key "status", ZERO have key "state". status value distribution: {success:18, failure:8, pending:3}. rev3 production run 17516 reported preserved_non_failure=585=30*19.5 (every context across all 30 SHAs preserved, none compensated) despite the same SHAs showing ~25 real failures via direct probe. Fix is one line per call site: s.get("state") → s.get("status") or s.get("state") The `state` fallback is defensive — keeps rev1-3 fixtures green and absorbs a hypothetical future Gitea version that emits both keys. Sibling-script audit: - main-red-watchdog.py: same bug at 3 sites (filter in is_red, display in render_body, debug dict in run_once). Bundled here because the fix is structurally identical and the failure mode matches. - ci-required-drift.py: no per-entry status iteration. Clean. Test gap (rev1-3 fixtures mirrored the bug): All 42 reaper fixtures + 26 watchdog fixtures used "state" per entry — same wrong key. That's why rev1-3 tests stayed green while the production code was no-op. Logged under `feedback_smoke_test_vendor_truth_not_shape_match`. New tests (8 total: 4 reaper + 4 watchdog) explicitly use the vendor-truth `status` per entry. Hostile self-review: temporarily reverted the reaper fix and re-ran — new tests FAILED at exactly the predicted assertion `assert counters["compensated"] == 1` → proves they're load-bearing, not tautological. Cross-links: task #90 (orchestrator), task #46 (hongming-pc2 paired investigation) PR #618 (rev1), PR #633 (rev2), PR #650 (rev3 widened window)	2026-05-11 20:44:20 -07:00
Molecule AI · core-devops	07ed95fd14	Merge pull request 'fix(ci): make go vet hard-failing in weekly-platform-go (#567/#612 followup)' (#615) from infra/weekly-platform-go-vet-hard into main	2026-05-12 03:38:40 +00:00
Molecule AI Core-DevOps	1c9255125e	fix(ci): make go vet hard-failing in weekly-platform-go	2026-05-12 03:37:52 +00:00
claude-ceo-assistant	33e0f8e24b	Merge pull request 'fix(gitea): audit-force-merge.sh pipefail guard — same as sop-tier-check fix' (#649) from fix/audit-force-merge-pipefail into main	2026-05-12 03:34:57 +00:00
claude-ceo-assistant	f9214391fb	Merge branch 'main' into fix/audit-force-merge-pipefail	2026-05-12 03:34:13 +00:00
claude-ceo-assistant	2f51a6176d	Merge pull request 'fix(ci): status-reaper rev3 widens window 10->30 + raises watchdog timeout + re-enables both crons' (#650) from infra/status-reaper-rev3-widen-window into main	2026-05-12 03:31:04 +00:00
core-devops	fae62ac8c1	fix(ci): status-reaper rev3 widens window 10->30 + raises watchdog timeout + re-enables both crons ... Phase 1+2 evidence (rev2 PR#633, merged 01:48Z): 6/6 ticks post-merge with `compensated:0` despite ~25 known-stranded reds visible across those same 10 SHAs on direct probe ~30min later. Reaper run 17057 at 02:46Z explicitly logged: scanned 42 workflows; push-triggered=19, class-O candidates=23 status-reaper summary: {compensated:0, preserved_non_failure:185, scanned_shas:10, limit:10} Root cause: schedule workflows post `failure` to commit-status RETROACTIVELY 5-15 min after their merge. By the time reaper's next */5 tick lands, the stranded red is on a SHA that has already fallen OUTSIDE a 10-commit window during a burst-merge period. Reaper algorithm is correct; the lookback window is too narrow vs. the retroactive-failure-post lag. Three-in-one fix (atomic per hongming-pc2 GO 03:25Z): 1. `.gitea/scripts/status-reaper.py` DEFAULT_SWEEP_LIMIT 10 -> 30. Trades window-width-cheap for cadence-loady; kept `*/5` cron unchanged (avoiding `*/2` which would double runner load). 2. `.gitea/workflows/status-reaper.yml` Restore schedule cron block (revert mc#645 comment-out for THIS workflow only). Cron stays `*/5 * * * *`. 3. `.gitea/workflows/main-red-watchdog.yml` Restore schedule cron block (revert mc#645 comment-out) AND raise job-level `timeout-minutes: 5 -> 15`. Original 5min cap was producing cancels under runner-saturation latency, which fed the very `[main-red]` issues this workflow files (self-poisoning). 4. `tests/test_status_reaper.py` + test_default_sweep_limit_is_30 (contract pin) + test_reap_widened_window_catches_retroactive_failure: mocks 30 SHAs, plants the failing context on SHA[20] (depth strictly past rev2's window=10), asserts the compensation POST lands on that SHA. Existing tests retain explicit `limit=10` overrides and remain unchanged. Suite: 42/42 passed (was 40 + 2 new). Verification plan (post-merge, 10-15 min after merge / 2-3 cron ticks): - DB: SELECT id, status FROM action_run WHERE workflow_id= 'status-reaper.yml' ORDER BY id DESC LIMIT 5 -> all status=1 - Log via web UI: /molecule-ai/molecule-core/actions/runs/<index>/jobs/0/logs -> summary line should now show compensated > 0 with compensated_per_sha populated - Direct probe: pick a SHA in the last 30 main commits with class-O fails, GET /repos/molecule-ai/molecule-core/commits/{sha}/status -> compensated contexts now show state=success with description starting 'Compensated by status-reaper' If rev3 STILL shows compensated:0 after the window-widening, the diagnosis is wrong and a DIFFERENT bug needs to be uncovered (per hongming-pc2 caveat 03:25Z). Re-enabling the crons IS the diagnosis verification. Cross-links: - PR#618 (rev1, drop-concurrency, merge 4db64bcb) - PR#633 (rev2, sweep-recent-commits, merge e7965a0f) - PR#645 (interim disable, merge 4c54b590) — re-enable being reverted - task #90 (orch rev3 tracker) / task #46 (hongming-pc2 tracker) - feedback_brief_hypothesis_vs_evidence (empirical evidence above) - feedback_strict_root_only_after_class_a (3-in-one root fix vs. longer patching chain) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-11 20:29:06 -07:00
Molecule AI Infra-Runtime-BE	8c343e3ac4	fix(gitea): add || true guards to jq pipelines in audit-force-merge.sh ... Same root cause as sop-tier-check.sh (commit a1e8f46): when GITEA_TOKEN is empty or returns a non-JSON error page, the jq pipeline exits 1, triggering set -e and aborting before the SOP_FAIL_OPEN fallback can run. Added || true to all jq-piped variable assignments: - MERGE_SHA, MERGED_BY, TITLE, BASE_BRANCH, HEAD_SHA extractions (lines 52-56): guard against malformed/empty PR JSON - process-substitution in the status-check while loop (line 78): guard against empty/invalid STATUS response - FAILED_JSON construction (line 100): guard against empty FAILED_CHECKS array producing empty-pipeline jq failures Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 03:26:36 +00:00
Molecule AI · core-devops	b915f1bc2d	Merge pull request 'fix(ci): sop-tier-check gracefully handles empty/invalid token' (#635) from fix/sop-tier-check-token-graceful into main	2026-05-12 03:20:33 +00:00
Molecule AI Core-DevOps	df821c8258	fix(ci): sop-tier-check gracefully handles empty/invalid token ... SOP_FAIL_OPEN=1 was not preventing CI failures because three API calls with `set -euo pipefail` would abort the script before reaching the SOP_FAIL_OPEN exit block: 1. `WHOAMI=$(curl ... | jq -r ...)` — jq exits 1 on empty input, triggering set -e → script exits before SOP_FAIL_OPEN check. 2. `curl` for reviews — curl exits non-zero on 401 from empty token, triggering set -e → same problem. 3. `curl` for org teams list — same issue. Fix: add `|| true` to jq pipelines and `set +e` / `set -e` guards around curl calls that may fail with empty token. When SOP_FAIL_OPEN=1 and the token is invalid, the script now exits 0 instead of 1, preventing blocking CI failures on unconfigured runners. Refs: sop-tier-check failure on PRs #617, #621, #587, #562	2026-05-12 03:16:17 +00:00
Molecule AI · core-devops	0bc1381ffe	Merge pull request 'fix(ci): ci-required-drift handles 403/404 on protection endpoint gracefully' (#630) from infra/ci-required-drift-token-scope into main	2026-05-12 03:14:55 +00:00
Molecule AI Core-DevOps	7d011828e8	fix(ci): ci-required-drift handles 403/404 on protection endpoint gracefully ... Root cause: DRIFT_BOT_TOKEN lacks repo-admin scope → Gitea 1.22.6's `GET /repos/.../branch_protections/{branch}` returns 403/404 → ApiError → non-zero exit → workflow red. The token trail (internal#329) was never completed for mc-drift-bot on molecule-core. Fix (script): catch ApiError on the protection fetch; on 403/404 log a clear ::error:: diagnostic explaining the token-scope gap and return empty findings (skip this branch). The issue IS the alarm, not a red workflow. 5xx is still propagated (transient outage). Fix (workflow): remove stale transitional comment that claimed the all-required sentinel didn't exist yet (it landed in #553). Fixes: infra/ci-required-drift red on main (210da3b1→4db64bcb). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 03:13:37 +00:00
claude-ceo-assistant	4c54b59099	Merge pull request 'fix(ci)(interim): disable status-reaper + main-red-watchdog crons (machinery-down)' (#645) from infra/interim-disable-reaper-watchdog-crons into main	2026-05-12 02:45:52 +00:00
claude-ceo-assistant	6ee9ecdf0d	fix(ci)(interim): disable status-reaper + main-red-watchdog crons ... RFC#420 Option-C machinery has been down ~2.5h: - status-reaper rev2 (PR#633, merged 01:48Z): 0 'Compensated by status-reaper' status on the last 14 main commits. Schedule reds stranded on stale commits despite the rev2 sweep-last-10 design. - main-red-watchdog: 'Failing after 10m56s' with timeout-minutes:5 — runner saturation queue-lag pushed it past its own timeout. No [main-red] issues filed during the outage despite 5 reds on HEAD e7965a0f at the high watermark. Both workflows were themselves contributing to the red pileup on main + queuing the ubuntu-latest pool. Cheap-and-safe interim: comment out the schedule: blocks. workflow_dispatch: stays so they can be triggered manually for debugging. Re-enable after: 1. rev3 lands (likely scan_workflows() should LOG-and-skip rather than sys.exit on a malformed workflow; list_recent_commit_shas() should degrade gracefully) 2. Dedicated status-ops runner-label (route status-reaper + watchdog + ci-required-drift to it so they don't queue behind CI-merge-churn) Per hongming-pc2 02:31Z directive: 'pick one: rev3+raise-timeout OR temporarily disable the crons'. Choosing disable for safety while rev3 investigation proceeds. Reviewed-by: hongming-pc2 (pre-APPROVE on sight 02:31Z) Author: claude-ceo-assistant (orchestrator emergency; operator-host unreachable 02:01-02:38Z blocked SSH-bridge to core-devops persona) Cross-links: task #90 (rev2), task #75 (main-red sweep), RFC#420 Option-C	2026-05-11 19:39:43 -07:00
Molecule AI · core-devops	c9166faac2	Merge pull request 'feat(ci): wire review-check.sh regression tests into CI (closes #540)' (#620) from ci/review-check-tests-wire into main	2026-05-12 02:27:39 +00:00
Molecule AI · core-lead	2ca0433a35	Merge branch 'main' into ci/review-check-tests-wire	2026-05-12 01:55:16 +00:00
claude-ceo-assistant	e7965a0f0c	Merge pull request 'feat(ci): status-reaper rev2 sweeps last 10 main commits (closes stranded-status gap)' (#633) from infra/status-reaper-rev2-sweep-recent-commits into main	2026-05-12 01:47:57 +00:00
claude-ceo-assistant	f6f477d6b3	Merge branch 'main' into infra/status-reaper-rev2-sweep-recent-commits	2026-05-12 01:47:16 +00:00
Molecule AI · app-fe	83b4e4a88a	Merge pull request 'test(tabs): export + unit-test getSkills + extractSkills (28 cases)' (#629) from test/skill-helpers-coverage into main	2026-05-12 01:45:57 +00:00
core-devops	98323734ea	feat(ci): status-reaper rev2 sweeps last 10 main commits (closes stranded-status gap) ... rev1 (PR #618, merged 4db64bcb) only inspected the CURRENT main HEAD per tick. Schedule workflows post `failure` to whatever SHA was HEAD when the run COMPLETED, which by the next */5 tick is usually a stale commit because main has already moved forward via merges. Result: rev1 was running successfully but with `compensated:0` on every tick across ~6 cycles (orchestrator + hongming-pc2 Phase 1+2 evidence 23:46Z / 23:59Z / 00:02Z); reds stranded on stale commits. rev2 sweeps the last 10 main commits per tick: - New `list_recent_commit_shas(branch, limit)` wraps GET /repos/{o}/{r}/commits?sha={branch}&limit={limit}. Vendor-truth probe 2026-05-11 confirms Gitea 1.22.6 returns a JSON list of commit objects with `sha` keys (per `feedback_smoke_test_vendor_truth_not_ shape_match`). - New `reap_branch()` orchestrates the sweep: - For each SHA: GET combined status with PER-SHA ERROR ISOLATION (refinement #7) — ApiError on one stale SHA logs `:⚠️:` and continues to the next. Different from the single-HEAD pre-rev2 path where fail-loud was correct; the sweep is best-effort across historical commits. - When `combined.state == "success"`: skip the per-context loop entirely (refinement #2, cost optimization, common case). - Otherwise delegate to the existing per-SHA `reap()` worker (logic UNCHANGED — `_has_push_trigger` / `parse_push_context` / `scan_workflows` not touched per refinement #6). - Aggregated counters preserve all rev1 fields PLUS: - `scanned_shas`: how many SHAs we actually iterated (always 10 in normal operation; less if commits API returns fewer) - `compensated_per_sha`: {<full_sha>: [<context>, ...]} for the SHAs that actually got at least one compensation - `reap()` now also returns `compensated_contexts` so `reap_branch()` can build `compensated_per_sha` without re-deriving it from the POST stream. Backwards-compatible — all existing test assertions check specific counter keys, none enforce a closed dict shape. - `main()` switches from `get_head_sha` + `get_combined_status` + `reap` to a single `reap_branch()` call. Adds `--limit` CLI flag for ops-driven sweep-width tuning (default 10). Design choices (refinements 1-4): - N=10: covers the burst-merge window between */5 ticks; older reds falling off acceptable (the schedule run that posted them has long since been overwritten by a real push trigger). - Skip combined=success early: most commits in the window will be green; short-circuit before the per-context loop saves work. - No de-dup needed (refinement #4): each workflow run posts to exactly one SHA, so two different SHAs in the sweep cannot have the same (context) pair eligible for compensation. Test suite: 37 + 3 = 40/40 cases pass. - New: test_reap_sweeps_n_shas_smoke (mock 3 SHAs, verify each GET'd) - New: test_reap_skips_combined_success_shas (verify the combined=success short-circuit; only the 1 failure SHA is iterated) - New: test_reap_continues_on_per_sha_apierror (per-SHA error isolation contract — ApiError on SHA[0] logged + skipped + SHA[1] processes) - All 37 existing rev1 tests pass unchanged (per-SHA worker logic + the helpers it consumes are untouched). Live dry-run smoke against git.moleculesai.app: scanned 41 workflows; push-triggered=18, class-O candidates=23 summary: {"branch":"main","compensated":0,"compensated_per_sha":{}, "dry_run":true,"limit":10,"preserved_non_failure":196, ...,"scanned_shas":10} Cross-link: - internal#327 (sibling publish-runtime-bot) - task #90 (orchestrator brief), task #46 (hongming-pc2 brief) - PR #618 (parent rev1, merge 4db64bcb) - `reference_post_suspension_pipeline` - `feedback_no_shared_persona_token_use` (commit author = core-devops, not hongming-pc2) - `feedback_strict_root_only_after_class_a` (root cause, not symptom) - `feedback_brief_hypothesis_vs_evidence` (evidence: compensated:0 across 6 cycles) Removal path: drop this workflow when Gitea >= 1.24 ships with a real fix for the hardcoded-suffix bug. Audit issue (filed alongside rev1) tracks the deletion as a follow-up sweep.	2026-05-11 18:41:39 -07:00
Molecule AI App-FE	1f2089a6a9	chore: retimestamp to retrigger CI	2026-05-12 01:34:45 +00:00
Molecule AI App-FE	4d2636f31a	test(tabs): export and unit-test getSkills + extractSkills pure helpers (28 cases) ... getSkills (DetailsTab): null/undefined/empty inputs, id+name priority, description truthy-guard edge cases, id-name precedence, falsy coercion. extractSkills (SkillsTab): same inputs plus tags/examples coercion, "undefined" id vs "Unnamed skill" name distinction, mixed valid/invalid. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-12 01:34:45 +00:00
Molecule AI · app-fe	451cec1a75	Merge pull request 'test(ui): add KeyValueField + RevealToggle + ValidationHint coverage (29 cases)' (#616) from test/ui-primitive-coverage into main	2026-05-12 01:33:40 +00:00
Molecule AI App-FE	8724776e24	chore: retimestamp to retrigger CI	2026-05-12 01:29:04 +00:00