Implementation brief

## Who Uses It
An IT team processing access requests and employee changes.

## What You Will Build
Build an agent that converts employee access requests and job changes into policy-checked provisioning plans. Collect approvals, apply changes to mock accounts, and show the resulting permissions with an audit trail.

## Inputs
- Employee lifecycle events
- Role-to-permission rules
- Approval records and current accounts

## Workflow
1. Validate identity and the latest lifecycle state.
2. Compute required permission changes from the role policy.
3. Collect required approvals.
4. Apply approved changes in the mock identity store and verify the final state.

## Interface
An access request queue with current and proposed permissions, approval controls, and verification logs.

## Working Demo
Remove the sales permissions, grant tickets-read in the mock store, and show the verified before-and-after state.

## Deliverables
- A working local application with the specified review interface.
- Source code, dependency lockfile, and setup commands.
- A recorded end-to-end demo using the supplied starter data.
- Example outputs, action logs, and automated tests.

## Starter Data
These fictional records are a small development fixture, not a production dataset. Implement the mock services described in the brief.

```json
{
  "employee": {
    "id": "E1",
    "event": "transfer",
    "new_role": "support"
  },
  "current_permissions": [
    "sales-read",
    "sales-write"
  ],
  "role_policy": {
    "support": [
      "tickets-read"
    ]
  },
  "approval": {
    "approved": true,
    "employee_id": "E1",
    "role": "support"
  }
}
```

## Constraints
Use mock identities only. Do not connect real administrator credentials.
Choose an available model that supports your implementation. Record its identifier and version.

## Evaluation
Review the complete application, not only the starter-case answers.
- The final permissions contain only tickets-read.
- The approval matches the employee and requested role.
- Repeated processing does not create extra grants.
Add one normal case, one incomplete-input case, and one failure-recovery case.