Repository navigation
Stale validation remediation notifications lack asset IDs and target candidate assets #599
Description
Stale / inconsistent validation remediation notifications
Summary
The authenticated account notification center shows 15 Validation Update Requested batches with counts:
1, 1, 5, 16, 6, 81, 3, 9, 3, 1, 2, 5, 16, 15, 1 (sum of batch counts: 165).
However, the notification View details action redirects only to the generic My Agent Nodes page and does not expose affected asset IDs.
Bound nodes
node_631139df3c1e(OpenClaw)node_b16736daee7a(Hermes)
API observations
- Authenticated
POST /a2a/heartbeatfor the Hermes node: HTTP 200, nopending_eventsfield/events. - Authenticated
GET /a2a/assets/published-by-me: HTTP 200 butcount: 0for both nodes. - The web node cards show Published counts of 1 and 2, respectively.
- Official
evolver sync --scope=published --dry-run --include-unpublished-listreportspublished: 0 asset(s)for both isolated node identities. - Penalty history currently contains no validation/remediation penalty for either node.
The dry-run command also seeded an ignored local .evolver/gep/genes.json while reporting (dry-run mode: no files were modified). The generated file was removed after verification.
Local-to-Hub audit
The local GEP store contains 238 Hub-synced Genes. Applying the current documented validation-command gate produced 64 unique candidate assets:
- 35 with commands not starting with
node,npm, ornpx - 29 with empty validation lists
Each of these 64 asset IDs was queried individually through GET /a2a/assets/:id:
- 64
candidate - 0
promoted - 60 owned by
node_631139df3c1e - 4 owned by
node_b16736daee7a
The documentation says validation remediation applies to promoted Genes, so the notifications appear stale, duplicated, or incorrectly generated for candidate assets.
Expected behavior
View detailsshould show or link to the affected asset IDs.- Remediation notifications should be generated only for assets currently eligible for remediation.
- The web Published count and
published-by-meresponse should agree. - Stale remediation tasks should be closed when an asset is no longer promoted/eligible.
Request
Please identify the remediation task IDs / affected asset IDs for this account, clear stale tasks, and confirm whether candidate assets are subject to reputation penalties.
No credentials or account session data are included in this report.
Activity
owenshen0907 commentedon Jul 12, 2026
🤖 @bjw9808 这条 issue 在你负责的仓库,麻烦认领或跟进一下。(agent-control 自动提醒;未自动接入)
njiangk commentedon Jul 12, 2026
User-side remediation update after the original report:
POST /a2a/asset/validation-updateto the real Evolver validatornode scripts/validate-suite.js.3095 test(s) passed, 0 failed.accepted / validation_updated, 52 returned the idempotentnoop / validation_unchanged; 0 errors.pending_events: 0.task_resolved: true; notification batches still do not expose remediation task IDs or an asset mapping.noop/validation_credible=false) and do not expose the mutable validation value, so the validation-update endpoint response is currently the only write confirmation available.Could the Hub team confirm whether the remaining aggregated notifications are stale and close/recompute any unresolved tasks server-side?
imxyanua commentedon Jul 12, 2026
@njiangk I will check, thank you for your feedback
please wait
autogame-17 commentedon Jul 13, 2026
On the client-side detail in this report — the dry-run that seeded a local file:
Confirmed and fixed (committed in the private dev repo, going through release).
evolver sync --dry-runcalledloadGenes(), which first-run-seedsgenes.jsonviaensureGenesSeeded()before the dry-run guard was reached — so the run genuinely wrote the file while printing "no files were modified". The fix adds a read-onlyloadGenes({ seed: false })used on the dry-run path, so a dry-run now leaves the store untouched. Verified end-to-end:sync --scope=published --dry-run --include-unpublished-listno longer creates.evolver/gep/genes.json.The rest of the report (stale/aggregated
Validation Update Requestednotifications, missing asset-ID mapping inView details, and the web Published count vspublished-by-medisagreement) is Hub-side and outside this client repo — leaving that to the Hub team already tracking it. This comment only covers the dry-run write bug.