Reconciles repository state after the local toolchain moved to Flutter 3.47.0
/ Dart 3.13.0. No product code changed - no lib/ or test/ file was modified.
Working tree drift:
1. analysis_options.yaml churn (accepted, 11 files). Flutter 3.47 ships
AnalysisOptionsMigration, which unconditionally writes a fixed
analyzer.exclude block into every analysis_options.yaml. It runs from
ensureReadyForPlatformSpecificTooling, so pub get / analyze / run / build
all restore it, and there is no opt-out (flutter#191160, flutter#191131).
Commit
|
||
|---|---|---|
| .. | ||
| build | ||
| lib | ||
| test | ||
| .gitignore | ||
| .metadata | ||
| CHANGELOG.md | ||
| LICENSE | ||
| README.md | ||
| analysis_options.yaml | ||
| pubspec.yaml | ||
README.md
Order management for the Kell Creations operations platform. Covers both
standard catalogue orders and made-to-order custom commissions behind a single
Order aggregate and one OrdersRepository contract.
Features
- Domain model —
Order,OrderItem,OrderStatus,OrderSource,OrderType,PaymentMethod,PaymentResult. - Custom orders —
CustomOrderSpec(material, colour, size, dimensions, reference images, notes, estimated completion) andDepositInfo(deposit and total amounts in integer cents, deposit/settlement dates, derived balance). - Fulfillment pipeline —
FulfillmentStatuswith enforced transitions:quoted → depositReceived → inProduction → qualityCheck → readyForPickup → completed, pluscancelledfrom any non-terminal stage and aqualityCheck → inProductionrework path. Illegal jumps are rejected by the domain, not silently applied. - Repository contract —
OrdersRepositorywith read, status, note, and create operations pluscreateCustomOrder,updateCustomOrderSpec,recordDeposit, andadvanceFulfillmentStatus. - Implementations —
FakeOrdersRepository(seeded standard and custom orders across every pipeline stage) andWooCommerceOrdersRepository(REST API v3, custom order state round-tripped through_kc_-prefixed order meta-data). - Application layer —
OrdersController,CheckoutController, and theGetOrders/UpdateOrderStatus/AddOrderNote/CreateOrderuse cases. - Presentation —
OrdersPage,OrderCard,OrderDetailPanel,OrderStatusChip.
Getting started
Add the package as a path dependency and import the barrel:
dependencies:
feature_orders:
path: ../feature_orders
import 'package:feature_orders/feature_orders.dart';
Usage
final repository = FakeOrdersRepository(logger: observability.logger);
final result = await repository.createCustomOrder(
order,
spec: CustomOrderSpec(
material: 'Organic cotton',
color: 'Sage green',
size: 'Large',
),
deposit: const DepositInfo.quoted(
totalAmountCents: 7200,
depositAmountCents: 2400,
),
);
// Advance through the pipeline — illegal jumps are rejected.
await repository.recordDeposit(
order.id,
amountCents: 2400,
paidAt: DateTime.now(),
);
await repository.advanceFulfillmentStatus(order.id, FulfillmentStatus.inProduction);
Observability and privacy
Repository implementations accept an optional KcLogger from core. Failed
and rejected write operations are logged with the operation name, order ID, and
status names only. Customer identity, addresses, money amounts, and deposit
payment identifiers are never logged, and every context map is additionally
passed through KcRedactor. There are no silent catch (_) {} blocks.
The WooCommerce meta-data mapping deliberately excludes the deposit
transaction ID — it lives on PaymentResult alone. See the class-level
documentation on WooCommerceOrderMapper for the complete key table.
Additional information
Part of the kell_creations_apps monorepo. Run the package tests with
flutter test from this directory, or the whole suite with
./tools/run_all_tests.sh --analyze from kell_creations_apps/.