Resolve permit_params in controller context, and two form-description fixes

[lloydwatkin]

🤖 Closes #18. Findings 1–3 fixed, finding 4 documented, plus the testing rule that would have caught all three.

1. Block-form permit_params made a resource unwritable

ActiveAdmin instance_execs a block-form permit_params on the controller. RecordWriter#resolve_permitted and FormDescription#permitted_names both resolved it against a bare @config.controller.new, so a block reading controller state raised NameError — and the rescue that exists to recognise a resource with genuinely no permit_params swallowed it.

permit_params do
  current_admin_user.super_admin? ? [:title, :body, :status] : [:title]
end

create, update and describe_form all refused such a resource with Resource declares no permit_params, so nothing may be written — not merely unhelpful, but wrong. Both now resolve against a controller carrying the MCP user, which ControllerDispatcher#controller_with_mcp_user already existed to provide.

2. A form block declaring no inputs reported nothing writable

return describe(action, "form", declared) if declared — [] is truthy, so form do |f| f.inputs; f.actions end (the shape of ActiveAdmin's own default_form_config, where Formtastic expands the inputs at render time) described zero attributes with source: "form". There is nothing in such a block to read, so it now falls back to the permitted params, as a resource with no form block already did.

3. inputs for: :association was flattened into the parent

Its fields belong to the associated record, and create/update drop them. has_many already reported a nested: group; both routes into an association's fields now behave the same.

4. Documented, not fixed

On the permit_params fallback path describe_form reports only column-backed fields, because the names are recovered by offering the controller every column and seeing which survive — so tag_ids and nested *_attributes keys are missing even though the write tools accept them. Now stated in the README rather than left implicit.

The part that matters more than the fixes

All three were in lines of ActiveAdmin's source quoted in the notes that justified the original changes — the block ? branch of params.permit(*permitted_params, param_key => block ? instance_exec(&block) : args), and the bare f.inputs in default_form_config. The information was not missing. Every fixture used the other branch, so no amount of running or mutating the suite could have failed on them.

CLAUDE.md gains a section, Cover the declaration shapes, not only the behaviours:

• For any ActiveAdmin construct this gem reads, enumerate the forms ActiveAdmin accepts and keep a fixture for each — permit_params as a list, a block, a block reading controller state, absent, or namespace-level; a form block with inputs, without, or nesting via has_many or inputs for:; a batch_action named by symbol or String title, with a hash or proc form:.
• When reading ActiveAdmin's source to answer a question, enumerate the branches you did not take.
• Mutation checking does not cover this and can disguise it. It proves a test is sensitive to a fixture changing; it says nothing about a shape no fixture has. Treat it as evidence about sensitivity, never as evidence of coverage.

That last point is the honest correction to how I reported the earlier PRs: "every new example was mutation-checked" was true, and I let it stand as though it meant the input space was covered.

Testing

• Unit: 248 examples. The harness gains Placement (block-form permit_params reading current_admin_user) and Roster (a form block leaving its inputs to Formtastic).
• E2E: 67 examples. The fixture app gains Assignment, carrying both shapes, and Review's form gains an inputs for: :post block.
• Each fix was verified by reverting it and confirming the new examples fail — the strongest available check, since it tests against the actual defect rather than a stand-in. All four new examples failed; restored and both suites re-run green.

🤖 Generated with Claude Code