Managed startup profile rejects schema-owned messaging runtime aliases

[ericksoa]

Investigation Summary

The complete unfiltered E2E run at latest PR commit 3cf9a57df9fb73ff8c75d75e79864dd2f5ba453e has six messaging jobs that fail before sandbox startup.

Each job reports:

Cannot build managed startup profile: Invalid managed startup profile: payload field messaging.plan.runtimeSetup.envAliases[1].value contains credential-shaped string data

The rejected value is a credential placeholder from the Slack channel manifest. It does not contain credential material.

Reproduction Steps

1. Dispatch the complete unfiltered E2E workflow at 3cf9a57df9fb73ff8c75d75e79864dd2f5ba453e.
2. Run the managed Docker messaging targets.
3. Observe onboarding fail while it builds the managed startup profile.

Environment

• Workflow: complete unfiltered E2E run 32091896540
• Latest PR commit: 3cf9a57df9fb73ff8c75d75e79864dd2f5ba453e
• Driver: OpenShell Docker driver

Failure Evidence

• messaging-providers
• Hermes isolates Slack credentials and reaches Slack APIs
• Hermes preserves channels across stop and start
• OpenClaw shares Slack pairing approval
• OpenClaw preserves channels across stop and start
• Messaging rotates one provider token without rebuilding siblings

Root Cause

The Slack channel manifest declares runtime environment aliases for SLACK_BOT_TOKEN and SLACK_APP_TOKEN. The messaging compiler places those entries under messaging.plan.runtimeSetup.envAliases[*].

PR #9374 fixed #9355 by accepting schema-owned package pins and agent-render credential placeholders. It did not accept runtime environment alias fields.

The validator therefore rejects the canonical alias value. A value-only exception is incomplete because the sibling match field also contains openshell:resolve:env: and will be rejected next.

Acceptance Criteria

• The managed startup profile validator accepts canonical messaging.plan.runtimeSetup.envAliases[*] entries.
• Each accepted alias must satisfy all of these conditions:
  • envKey is a valid credential environment name.
  • match is the canonical anchored OpenShell resolver expression for that envKey.
  • value is an approved credential placeholder for the same envKey.
• The validator continues to reject:
  • raw credentials;
  • malformed or unanchored alias expressions;
  • mismatched envKey, match, and value fields;
  • credential-placeholder strings at other payload paths.
• Focused regression tests cover both stock Slack aliases and each denial case.
• All six affected jobs pass in a complete unfiltered E2E run.

Out of Scope

The Discord pairing managed-bootstrap stability failure in job 95576208780 has a different failure signature and requires a separate issue.

Relationship

• Follow-up to Managed startup profile rejects schema-owned messaging placeholder fields #9355 and fix(onboard): accept schema-owned messaging plan fields #9374.
• Prerequisite for shipping feat(onboard): activate buildless managed onboarding #9323 and completing [Epic #7744 1/6][B3-E] Activate supported buildless managed onboarding #9140.
• Related epic: [Epic] Support native Podman with buildless managed onboarding #7744.

[ericksoa]

The complete unfiltered cutover run exposes another schema-owned messaging runtime field rejected after #9408:

• Run: https://github.com/NVIDIA/NemoClaw/actions/runs/32132319706
• Messaging providers: https://github.com/NVIDIA/NemoClaw/actions/runs/32132319706/job/95696286835
• OpenClaw channel restart: https://github.com/NVIDIA/NemoClaw/actions/runs/32132319706/job/95696290779
• Candidate: 774e2363ecdfed90502ebbcffa03a4ecb46fc50e
• Signature: messaging.plan.buildSteps[3].value.content.token is rejected as a credential-shaped field name.

Reopening this runtime-alias family until both lanes accept the schema-owned field while still rejecting unowned credential-shaped data.

[ericksoa]

Attempt 3 confirms the exact content.token recurrence after #9479:

• Full run: https://github.com/NVIDIA/NemoClaw/actions/runs/32223500282/attempts/3
• Candidate: a4f9b59aa64f88532a3e64e949dd1b4068aa1f1e
• messaging-providers: https://github.com/NVIDIA/NemoClaw/actions/runs/32223500282/job/96038487196
• Rejected path: messaging.plan.buildSteps[3].value.content.token

The candidate contains #9408 and #9479. Exact-commit artifact reproduction shows that the WeChat authorization passes the first profile scan, but the validator rebuilds the messaging plan with null-prototype objects before transport encoding. The second scan rejects the same stock step because the channel-owned authorization accepts only Object.prototype objects. The prior regression test called the validator once and did not exercise transport encoding.

The repair must accept the exact channel-owned WeChat account-file structure through both validation passes. Raw tokens, malformed or mismatched placeholders, unsafe paths or modes, and token fields at unowned paths must remain rejected.

[ericksoa]

The residual reproduces after the cutover branch refresh from current main.

• Refreshed cutover head: 8e2fd4325fb95c73cc3733c82d7b87d9459d61a7
• Integrated main: b1c0e21d4de5436a8fc5aba8596592a0fca0f986
• Reproduction: generate the stock WeChat openclawWeixinAccountFile build step, validate the managed startup profile once, then encode that validated profile for transport.
• Result: the second validation rejects messaging.plan.buildSteps[0].value.content.token because the cloned stock structure uses null-prototype JSON objects.

This confirms the exact content.token recurrence remains after current-main integration and needs the narrow stacked repair on #9323.