How to Handle Feature-Specific Parameter Requirements in a Repository Pattern Implementation?

Question

Best Approach to Handle Varying Parameters in Feature-Specific Implementations of an Abstract Repository in Dart

I have an abstract Repository<T> class in Dart that defines several methods, as shown below:

import 'package:qkons/core/errors/failures.dart';
import 'package:qkons/core/pagination/pagination_params.dart';
import 'package:qkons/core/pagination/pagination_res.dart';

abstract class Repository<T> {
  Future<({Failure? failure, T? value})> getOneById(
      {required String token, required String id});
  Future<({Failure? failure, PaginationResponse<T>? value})> getMany(
      {required String token, required PaginationParams params});
  Future<({Failure? failure, bool? value})> addOne(
      {required String token, required T value});
  Future<({Failure? failure, bool? value})> addMany(
      {required String token, required List<T> value});
  Future<({Failure? failure, bool? value})> deleteOne(
      {required String token, required String id});
  Future<({Failure? failure, bool? value})> deleteMany(
      {required String token, required List<String> ids});
  Future<({Failure? failure, bool? value})> enableTracking(
      {required String token});
  Future<({Failure? failure, bool? value})> disableTracking(
      {required String token});
}

I have a specific feature where an implementation of this repository requires different parameters than what's defined in the abstract class. For example, the addOne method may need an additional parameter, or the getMany method may need fewer parameters.

My Questions:

1. What is the best practice to handle this scenario in Dart?
2. Should I modify the base repository's method signatures to be more generic (e.g., using a Map for parameters)?
3. Would it be better to create an entirely new interface for this specific implementation?
4. Are there other approaches (e.g., dependency injection or mixins) that could help in adhering to good design principles?

Additional Context:

I'm aiming to maintain a clean architecture and keep my code extensible for future features. I want to avoid breaking the current design or introducing unnecessary complexity.

Any suggestions or examples would be greatly appreciated!