There's a type/implementation mismatch for field-level beforeOperation hooks during create operations. The type definition (lines 150-156) doesn't include an item parameter for create operations, but the implementation (line 109 in context/index.ts) passes item: undefined anyway using a type assertion to bypass the type check.

This creates an inconsistency where:

1. TypeScript types say item is not available for create operations
2. But at runtime, item is present in the arguments object (with value undefined)

For consistency with list-level hooks and to avoid confusion, either:

1. Update the type definition to include item?: undefined for create operations (making it explicit that it's undefined), or
2. Update the implementation to not pass item at all for create operations by separating the create case from the update case (lines 94-112 in context/index.ts)

Option 2 would be more consistent with how list-level beforeOperation is called (see line 694-700 in context/index.ts where no item is passed for create).

The field-level validate hook is defined in the type system (lines 98-128) but is never actually executed in the implementation. While list-level validate hooks are executed via executeValidate in the context files, there is no corresponding execution for field-level validate hooks.

This creates a discrepancy between the API surface (what the types promise) and the actual behavior (what the code does). Developers who define field-level validate hooks will expect them to run, but they will be silently ignored.

Either:

1. Implement execution of field-level validate hooks in the context files (similar to how executeFieldResolveInputHooks and executeFieldBeforeOperationHooks work), or
2. Remove the validate hook from the FieldHooks type definition if it's not intended to be supported at the field level

Note: This appears to be a new feature added in this PR (field-level validate), so it should be fully implemented or removed before merging.

The documentation incorrectly states that the operation parameter can be 'create', 'update', 'delete', or 'query' for hooks. However, based on the actual hook type definitions and implementation:

1. List-level and field-level hooks for resolveInput, validate, beforeOperation, and afterOperation only support 'create', 'update', and 'delete' operations
2. The 'query' operation is only relevant for the resolveOutput hook, which is a special read-only hook

This line should be corrected to accurately reflect that most hooks only receive 'create', 'update', or 'delete' as the operation type, and 'query' is specific to resolveOutput (which is mentioned separately on line 202).

The documentation states that field-level validate hooks support delete operations (line 193), but there is no implementation in the codebase that actually executes field-level validate hooks. This documentation is misleading and should either be:

1. Removed if field-level validate hooks are not intended to be supported, or
2. Kept only if the implementation is added to actually execute these hooks

This is related to the missing implementation of field-level validate hook execution in the codebase.

The changeset claims "All hooks now support validate hook for field-level validation" but this is not accurate. While the type definition for field-level validate hooks exists in the code, there is no implementation that actually executes these hooks.

This statement should be removed or modified to only mention list-level validate hooks, since field-level validate hooks are defined but not implemented.

The example in the spec file doesn't demonstrate the new hook parameters that are part of this PR. The validateInput hook here doesn't show the new listKey or inputData parameters. While backward compatibility is maintained, this spec file should ideally demonstrate the updated API to serve as a proper example for developers. Consider updating this example to show: validateInput: async ({ listKey, operation, inputData, resolvedData, item, context, addValidationError }) => {

The documentation states "use fieldKey, not fieldName" but then shows resolveOutput hook using fieldName instead of fieldKey. This creates an inconsistency in the documentation. Either resolveOutput should also be updated to use fieldKey for consistency (in a future PR), or this documentation should clarify why resolveOutput is an exception to the fieldKey convention.

The PR description states "Backward compatibility is maintained where possible through deprecated aliases and parameter additions (not removals)". However, this isn't entirely accurate. The field-level hooks have several parameter removals that are breaking changes:

1. inputValue parameter was removed from resolveInput (replaced with accessing resolvedData[fieldKey])
2. fieldName was renamed to fieldKey in most hooks (breaking change, not backward compatible)
3. resolvedValue was removed from beforeOperation
4. value was removed from afterOperation

These are documented in the changeset migration guide, but the PR description's claim about backward compatibility through "parameter additions (not removals)" is misleading. Consider updating the PR description to be more accurate about the breaking changes in field-level hooks.