lhumina_code/hero_proc
2
0
Fork 0
Code Issues 26 Pull requests Projects Releases 3 Packages Wiki Activity Actions

Restore context-aware secrets on the multi-domain OpenRPC API #163

New issue
Closed
opened 2026-06-23 22:44:32 +00:00 by mik-tf · 1 comment
mik-tf commented 2026-06-23 22:44:32 +00:00
Owner
Copy link

Problem

The new hero_proc multi-domain secrets OpenRPC surface currently exposes rootobject-style secret CRUD that identifies a secret only by sid/key, while the server implementation defaults every secret operation to the core context.

That breaks the existing Hero secret model: secrets are context-scoped. The same key can legitimately exist in different contexts with different values.

This blocks the development-channel deployer convergence tracked at lhumina_code/hero_os_tfgrid_deployer#30 and the platform convergence program at lhumina_code/home_lhumina#313. The deployer needs context-scoped secrets for:

  • mainnet/testnet/QA compute daemon wallet and grid settings
  • deployer/cockpit organization and admin settings
  • per-engine tester bearer tokens for shared providers

Adapting deployer to a core-only secret API would compile toward the wrong behavior: values from different contexts would be read from or written to the wrong namespace.

Plan

  1. Keep the new multi-domain route shape (/api/secrets/rpc) and the one-input OpenRPC rule.
  2. Restore context-aware secret access in the typed secrets API. Use one-input structs for context-aware get/set/delete/list/find so the SDK can express { context_name, key } without relying on OS env or path-specific hacks.
  3. Preserve the existing SQLite model keyed by (context_name, key).
  4. Update CLI/admin callers so --context is honored again instead of ignored.
  5. Add tests that prove the same key can exist in two contexts and round-trip independently through the new OpenRPC surface.
  6. After this lands, update deployer to use the new typed context-aware methods and continue the development-channel deployer/cockpit convergence.

Acceptance

  • hero_proc_sdk exposes context-aware secret operations on the secrets() domain.
  • secret CLI commands with --context read/write/delete the requested context.
  • Two secrets with the same key in different contexts do not overwrite or shadow each other.
  • A server-side test covers set/get/delete or equivalent operations across at least two contexts.
  • The deployer can consume the development hero_proc_sdk without collapsing all secrets into core.

Signed-by: mik-tf mik-tf@noreply.invalid

## Problem The new `hero_proc` multi-domain secrets OpenRPC surface currently exposes rootobject-style secret CRUD that identifies a secret only by `sid`/key, while the server implementation defaults every secret operation to the `core` context. That breaks the existing Hero secret model: secrets are context-scoped. The same key can legitimately exist in different contexts with different values. This blocks the development-channel deployer convergence tracked at https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/30 and the platform convergence program at https://forge.ourworld.tf/lhumina_code/home_lhumina/issues/313. The deployer needs context-scoped secrets for: - mainnet/testnet/QA compute daemon wallet and grid settings - deployer/cockpit organization and admin settings - per-engine tester bearer tokens for shared providers Adapting deployer to a core-only secret API would compile toward the wrong behavior: values from different contexts would be read from or written to the wrong namespace. ## Plan 1. Keep the new multi-domain route shape (`/api/secrets/rpc`) and the one-input OpenRPC rule. 2. Restore context-aware secret access in the typed secrets API. Use one-input structs for context-aware get/set/delete/list/find so the SDK can express `{ context_name, key }` without relying on OS env or path-specific hacks. 3. Preserve the existing SQLite model keyed by `(context_name, key)`. 4. Update CLI/admin callers so `--context` is honored again instead of ignored. 5. Add tests that prove the same key can exist in two contexts and round-trip independently through the new OpenRPC surface. 6. After this lands, update deployer to use the new typed context-aware methods and continue the development-channel deployer/cockpit convergence. ## Acceptance - `hero_proc_sdk` exposes context-aware secret operations on the `secrets()` domain. - `secret` CLI commands with `--context` read/write/delete the requested context. - Two secrets with the same key in different contexts do not overwrite or shadow each other. - A server-side test covers set/get/delete or equivalent operations across at least two contexts. - The deployer can consume the development `hero_proc_sdk` without collapsing all secrets into `core`. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-23 23:13:36 +00:00
Author
Owner
Copy link

Progress update:

  • Added context-aware secrets schema/types on the multi-domain OpenRPC API: ContextSecretKey, ContextSecret, ContextSecretFilter plus get_context, set_context, delete_context, exists_context, list_context, and list_full_context.
  • Server implementation now maps those methods onto the existing (context_name, key) secret DB model, preserving the core/default CRUD methods for existing callers.
  • CLI secret commands now honor context again instead of ignoring it.
  • Restored the functional context-isolation case so the same key can round-trip independently in two contexts.
  • Checks passed: cargo +1.96 check -p hero_proc_sdk -p hero_proc_server -p hero_proc_cli -p hero_proc_admin -p hero_proc_test; git diff --check. The filtered hero_proc_test command compiled the runner crate but did not execute a standard #[test] because that suite is runner-driven.

Next sequencing step: publish/merge development_mik_secrets_context so deployer can consume the generated context methods from its normal Forge development dependency.

Signed-by: mik-tf mik-tf@noreply.invalid

Progress update: - Added context-aware secrets schema/types on the multi-domain OpenRPC API: ContextSecretKey, ContextSecret, ContextSecretFilter plus get_context, set_context, delete_context, exists_context, list_context, and list_full_context. - Server implementation now maps those methods onto the existing (context_name, key) secret DB model, preserving the core/default CRUD methods for existing callers. - CLI secret commands now honor context again instead of ignoring it. - Restored the functional context-isolation case so the same key can round-trip independently in two contexts. - Checks passed: cargo +1.96 check -p hero_proc_sdk -p hero_proc_server -p hero_proc_cli -p hero_proc_admin -p hero_proc_test; git diff --check. The filtered hero_proc_test command compiled the runner crate but did not execute a standard #[test] because that suite is runner-driven. Next sequencing step: publish/merge development_mik_secrets_context so deployer can consume the generated context methods from its normal Forge development dependency. Signed-by: mik-tf <mik-tf@noreply.invalid>
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
main
development_markup_admin
integration
development_freeze
development_cleanup_138
oschema_migration
feat/secrets-catalogue-hero-db-port
stopgap/openrpc-enforcement-b1
development_sameh_hp02
latest-development
latest-main
latest-integration
__scopecheck
__releaser_apitest
latest-dev
latest
lab-latest
v0.5.0-rc2
v0.5.0-rc1
v0.4.4
v0.4.1
v0.1.1
Labels
Clear labels   
prio_critical

   
prio_low

   
type_bug

   
type_contact

   
type_issue

   
type_lead

   
type_question

   
type_story

   
type_task
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_proc#163
No description provided.