(bug) Pi permissions controls are hidden when the agent config omits harness.kind

[mmabrouk]

When an agent config omits harness.kind, the runner treats the harness as pi_core: all seven Pi built-ins are active and the harness.permissions allow/ask/deny rules are enforced at runtime. The web UI does not apply the same default, so for such a config the Pi permissions controls are hidden while the run enforces Pi permission gating. The author cannot see or edit the rules that apply to their runs.

Where the gap is: in web/packages/agenta-entity-ui/src/DrillInView/SchemaControls/agentTemplate/useModelHarness.tsx, harnessValue stays null when harness.kind is absent (line 174), so isPiHarness is false (line 175) and hasPiPermissions (line 379) hides PiPermissionsControl.

This is a visibility gap only; the runtime permission gate (including allow_reads) still applies. The UI should treat an absent harness.kind as pi_core, matching the runner, with coverage for the {harness: {}} case.

Follow-up from a review comment on #5651: #5651 (comment)

[linear-code]

AGE-4059

[mmabrouk]

🤖 Step-by-step instructions for picking this up (written with coding agents in mind, but they work for humans too):

Steps

1. In web/packages/agenta-entity-ui/src/DrillInView/SchemaControls/agentTemplate/useModelHarness.tsx, line 174 leaves harnessValue as null when harness.kind is absent, so isPiHarness (line 175) and hasPiPermissions (line 379) are false and PiPermissionsControl never renders. Make an absent kind default to "pi_core" in the read path, so the resolved harness value is "pi_core" for both a missing harness key and an empty {harness: {}} object. The runner already treats an absent kind as pi_core, so this only aligns the UI with what actually runs.
2. harnessValue feeds more than the permissions block: the harness Select value (line 641), the model option groups (line 253), MCP support (line 198), the selected capabilities (line 612), and the section status (line 768). Defaulting to pi_core makes all of them show the Pi defaults, which is the runtime truth, but check two things by hand: the harness dropdown should now show Pi selected instead of empty for a config with no harness key, and editing an unrelated field must not silently write harness.kind: "pi_core" back into the saved config. Keep the default in the read path only; do not write a kind the author never set.
3. This package's tests are pure-function vitest tests under web/packages/agenta-entity-ui/tests/unit/ (there is no React renderer in the dev dependencies), so extract the defaulting into a small exported helper next to the hook and add a unit test covering a config with no harness key, {harness: {}}, and an explicit {harness: {kind: "claude"}} (which must not be overridden).

Validation

Run from the repo root; pass means both commands exit 0 with no lint errors or test failures.

cd web && pnpm lint-fix
cd web && pnpm --filter @agenta/entity-ui test

Manual check: open an agent config whose JSON has no harness key and confirm the Pi permissions controls (the Allow / Ask / Deny rule lists) now render, and that the harness selector shows the Pi default.

PR requirements

• Title follows the repo convention fix(frontend): <symptom-led title>, and the body follows the repo's PR style: lead with the symptom (permission rules enforced at runtime but invisible in the UI) and a before/after, ideally with a screenshot of the permissions section for a config without harness.kind.
• The PR description must include a section stating which AI model was used, at what thinking or reasoning budget, and a short summary of the conversation or session that produced the change, so reviewers can calibrate their review.
• Link this issue with Closes #5661.

[oforiwaasam]

Hi @mmabrouk, could you assign this to me?

[waterWang]

I'll take this one. The fix is straightforward — treat absent harness.kind as pi_core to match the runner's default, which will make isPiHarness and hasPiPermissions correctly evaluate to true when the config omits harness.kind.

[oforiwaasam]

Hi @mmabrouk, sorry about the delay in fixing this. I've addressed the issue in my PR #5706, including the comments I see you have raised in other previous prs. Please let me know if you have any other suggestions. If this pr ends up getting merged, I don't mind if we add others as contributors.