Framework RecipesImplementation, failure path, check

Rails · requirements checked during agent edits

Build a Rails update that keeps privileged fields out of agent edits

A profile form may allow a user to change display_name and timezone. A crafted request can also contain admin or role. Strong parameters remove those fields from the update input. Adding :admin during a refactor changes who can grant privileges.

Implement the requirement

Save this as app/controllers/profiles_controller.rb:

class ProfilesController < ApplicationController
  private

  def profile_params
    params.require(:profile).permit(:display_name, :timezone)
  end
end

The requirement is adapted from Perch’s public order-service example at commit 4af67af. The Rails implementation below is an illustrative adaptation, not a claim about that source project’s framework.

Create the Rails project

gem install rails
rails new checked-rails
cd checked-rails
bin/rails generate controller Profiles

Save the controller fragment below. In an authenticated application, call current_user.profile.update!(profile_params) from the update action, where current_user comes from your existing verified session. Do not use a client-supplied user ID to choose the profile. This guide tests the parameter boundary independently of your authentication library; the fragment does not supply sign-in or a public update route.

Start the development server with bin/rails server. Follow the Rails setup documentation for platform prerequisites. The framework API used here is documented in the official reference.

Test the broken and corrected behavior

Save this as test/controllers/profile_params_test.rb:

require "test_helper"

class ProfileParamsTest < ActiveSupport::TestCase
  test "profile fields exclude privilege changes" do
    controller = ProfilesController.new
    controller.params = ActionController::Parameters.new(profile: {
      display_name: "Ada", timezone: "UTC", admin: true, role: "owner"
    })
    allowed = controller.send(:profile_params).to_h
    assert_equal({"display_name" => "Ada", "timezone" => "UTC"}, allowed)
  end
end

Run bin/rails test test/controllers/profile_params_test.rb. Then make this deliberate regression: replace .permit(:display_name, :timezone) with .permit(:display_name, :timezone, :admin). The boundary test should fail. Restore the original before continuing.

Save the requirement as a Perch rule

Perch is an open-source semantic linter powered by SystemOne decision models. Save the following rule in .perch/rules/perch-guide-rails-intro.yaml at the repository root, keeping your existing perch.yaml:

- name: profile-field-allowlist
  where: "app/controllers/profiles_controller.rb"
  ensure: >-
    The profile_params method permits only display_name and timezone. It must not permit admin, role, or all parameters with permit! or an empty-hash allowlist.

Install the CLI and sign in, then check the working file:

npm install -g @lakeday/perch
perch login
perch check app/controllers/profiles_controller.rb --rules profile-field-allowlist --json

Use Node 22 or newer. perch login opens the authentication workflow. perch check reads the file currently on disk, so the agent can check an uncommitted edit. A rule finding exits 3; exits 1 and 2 mean the check did not complete. Read the JSON and the code before deciding what to change.

Captured Perch check

On October 14, 2026, we ran the rule above through Perch using jev-latest on the deliberately broken and corrected files.

Control Command exit Outcome
Broken implementation 3 Rule finding reported
Corrected implementation 0 No rule finding reported

The rule distinguished these two controls in this captured run. Fresh judgments can vary. Captured command output and the broken and corrected source are available for inspection.

Install the rule pack and configure your agent

Download this rule pack ZIP · Download the YAML rules · Agent task. The pack contains the rule, its example paths and the repair/recheck instructions. Review the where selector before using it in an existing project. Keep your root perch.yaml; install this rule as a separate file under .perch/rules/.

  1. Install Perch using Node 22 or newer and sign in once:
npm install -g @lakeday/perch
perch login
  1. Download the pack, inspect it, and extract it from your repository root. The extraction preserves any existing files:
curl -fL 'https://frameworkrecipes.dev/rails/intro/rule-pack.zip' -o 'perch-guide-rails-intro.zip'
unzip -n 'perch-guide-rails-intro.zip'

The installed rule is .perch/rules/perch-guide-rails-intro.yaml. Its selector matches app/controllers/profiles_controller.rb in this example; adapt the selector to your application file before checking an existing project.

  1. Configure the coding agent you use. Run one of these commands:

Claude Code:

perch setup claude-code

Codex:

perch setup codex

Cursor:

perch setup cursor

Pi:

perch setup pi
  1. Ask the agent to edit the implementation and check the saved requirement:

Use the installed Perch skill while editing app/controllers/profiles_controller.rb. Preserve profile-field-allowlist. Run perch check app/controllers/profiles_controller.rb --rules profile-field-allowlist --json after the edit. Read each finding and the affected code, fix the implementation, and run the identical check again after the fix. Keep the rule and regression tests intact. Run the application's relevant regression tests and report the commands and actual results. Exit 3 means a rule finding; exit 1 or 2 means the check did not complete. Report an unavailable or incomplete check as blocked. Do not claim the application tests ran if only the Perch check ran.

  1. After repairing a finding, run the same check again and inspect the result:
perch check app/controllers/profiles_controller.rb --rules profile-field-allowlist --json

Commit the downloaded rule and the installed agent configuration with your application. The rule file adds no guarantee of correctness; keep the regression tests from this guide.

Keep the checks within their scope

An allowlist does not establish ownership or authenticate the caller. Keep separate tests for verified sessions and authorization, and keep privileged operations behind explicit policies. This guide demonstrates the strong-parameters boundary only.

Fresh model judgments can vary. Unchanged requests can reuse cached answers. A passing rule check does not prove the application correct; keep the executable test as a separate check. Relevant source code is sent to the configured analysis service.

Published by Perch / Verglas LLC. Framework names identify the software used; this guide is not an official framework publication.