Kell Creations Operations Platform — Master Development Brief¶

Recommended repo location¶

Place this document in the repository at:

docs/development/master_development_brief.md

Why this location:

keeps it versioned with the code
makes it easy for Cline to read and update
separates implementation planning from feature code
works for both web and Android roadmap tracking

If docs/development/ does not exist yet, create it.

Purpose¶

This document is the master implementation brief for continuing development of the Kell Creations Flutter operations platform across web and Android. It is intended for use by Cline in Windows 11 VS Code.

This brief should be treated as the working source of truth for planned development after the current completed slices already landed on main.

Working model¶

Development must proceed in small, reviewable vertical slices.

Rules:

Branch from current main for each stage or sub-slice.
Implement on a feature branch.
Validate locally.
Open a PR into main.
Merge only after tests/analyze are clean.
Do not stack broad unfinished work directly on main.
After each merged slice, update this brief so it remains aligned to main.

Current confirmed baseline on `main`¶

Platform structure¶

apps/kell_web exists — active, wired to shared packages.
apps/kell_mobile exists — scaffolded as default Flutter template, not yet integrated with shared packages.
Shared packages include:
core — shared domain/application abstractions and cross-platform composition pattern (KcAppConfig, KcAppServices, KcBootstrap, KcAppScope)
design_system — theme (KcColors, KcSpacing, KcTheme), typography (KcTypography), layout (KcBreakpoints), and 7 shared widgets (KcCard, KcStatusChip, KcEmptyState, KcSectionHeader, KcSummaryCard, KcLoadingState, KcErrorState)
feature_inventory — domain, application, data (fake), and presentation layers
feature_wordpress — domain, application, data (fake + WooCommerce), and presentation layers (most mature feature)
feature_orders — domain, application, data (fake), and presentation layers
feature_policy — domain, application, data (fake), and presentation layers
Scaffolded but empty stub packages (created, no implementation yet):
auth — authentication/authorization (stub only)
data — shared data layer (stub only)
integrations — shared integration abstractions (stub only)
feature_finance — financial analysis feature (stub only)
feature_mrp — craft manufacturing/MRP feature (stub only)
feature_social — social media management feature (stub only)
tools/ directory contains CI helper scripts (run_all_tests.sh, collect_coverage.sh, README.md).
App shell, routing, dashboard, reusable shell widgets, AppServices, and AppScope are implemented.
Dashboard uses app-composed repository data.
Vertical slices exist for Inventory, Products/Publishing, Orders, and Policy/Governance.
Cross-feature navigation handoffs and shared filtering/search/selection persistence are implemented.
Runtime bootstrap uses:
KC_ENV
KC_WC_SITE_URL
KC_WC_CONSUMER_KEY
KC_WC_CONSUMER_SECRET
App supports FAKE and WP modes with visible shell badge.

Product publishing workflow already landed on `main`¶

Controlled WooCommerce publish action landed.
ProductDraft.copyWith landed.
unpublished -> draft UI exposure landed.
pendingReview -> draft UI exposure landed.
unpublished semantics clarified as a read-only abstraction.
Status action success/failure feedback landed.
Publishing page polish landed.
Richer read-side detail preview landed.
Price-only product edit landed.
Search/filter/sort refinement landed.
Name-only product edit landed.
✅ Description-only product edit landed (Stage 1A complete — merged feat/description-only-edit → main at cebac4c, 2026-04-11).
✅ Category-only product edit landed (Stage 1B complete — merged feat/category-only-edit → main at 8e7e4cb, 2026-04-11). Stage 1 complete.
✅ Post-write consistency hardening landed (Stage 2A complete — merged feat/post-write-consistency → main at 7acff83, 2026-04-11).
✅ Publishing workflow UX hardening landed (Stage 2B complete — merged feat/publishing-ux-hardening → main at b81016d, 2026-04-11). Stage 2 complete.
✅ Multi-select groundwork landed (Stage 3A complete — merged feat/multi-select-groundwork → main, 2026-05-22).
✅ List efficiency improvements landed (Stage 3B complete — merged feat/list-efficiency-improvements → main, 2026-05-22). Stage 3 complete.
✅ Design system expansion and shared widget migration landed (Stage 4A complete — merged feat/design-system-shared-widgets → main, 2026-05-22).
✅ Cross-platform shell composition strategy landed (Stage 4B complete — merged feat/shared-composition-pattern → main, 2026-05-22).
✅ Flutter CI/CD pipeline landed (Stage 4C complete — merged feat/flutter-cicd → main, 2026-05-22).
✅ Test coverage visibility landed (Stage 4D complete — merged feat/test-coverage-visibility → main, 2026-05-22).

Current narrow edit capabilities on `main`¶

update product status through controlled workflow
update product price only
update product name only
update product description only
update product category only

Latest known validation state on `main`¶

dart analyze clean
core tests passing
design_system tests passing
feature_wordpress tests passing
kell_web tests passing
latest reported count for core: 20/20 passed
latest reported count for design_system: 41/41 passed
latest reported count for feature_wordpress: 294/294 passed
latest reported count for kell_web: 24/24 passed
baseline commit: merge of feat/test-coverage-visibility (2026-05-22)

Baseline test coverage (established 2026-05-22)¶

Package	Tests	Lines Hit	Lines Found	Coverage
`core`	20	42	49	85.7%
`design_system`	41	88	88	100.0%
`feature_wordpress`	294	857	1012	84.7%
`kell_web`	24	191	353	54.1%
Total	379	1178	1502	78.4%

No minimum thresholds are enforced — this is visibility-only tracking. Coverage is measured via flutter test --coverage (generates lcov.info) and reported in the CI workflow summary table.

Next recommended branch¶

feat/android-app-shell — Stage 5A: Android app shell and bootstrap. Branch from latest main. Stage 4 (Platform foundations and cross-platform readiness) is complete.

Non-negotiable architectural constraints¶

These must be preserved in all future work:

Preserve strict package boundaries.
Fake repositories remain in feature packages.
Real integrations are incremental alongside fake ones.
Runtime selection stays via --dart-define, not a settings UI.
No credentials hardcoded or committed.
Do not broaden into generic product editing prematurely.
Keep WooCommerce details inside the WP repository layer.
Keep diffs small and reviewable.
Prefer inspection-first development.
Android support should reuse shared feature/domain/application layers rather than fork logic.

Development stages¶

Stage 1 — Web application completion: controlled product editing¶

Objective¶

Extend the publishing workflow with additional single-field edit capabilities using the same narrow pattern already established by price-only and name-only update.

Branching model¶

Use one branch per edit slice:

feat/description-only-edit
feat/category-only-edit

Stage 1A — Description-only product edit ✅ COMPLETE¶

Merged feat/description-only-edit → main at cebac4c (2026-04-11). All artifacts delivered: repository contract, fake/WP repo implementations, use case, controller action/result handling, preview panel inline description edit UI, and targeted tests (212 total feature_wordpress tests passing).

Stage 1B — Category-only product edit ✅ COMPLETE¶

Merged feat/category-only-edit → main at 8e7e4cb (2026-04-11). All artifacts delivered: repository contract, fake/WP repo implementations, use case, controller action/result handling, preview panel inline category edit UI, snack bar feedback, and targeted tests (223 total feature_wordpress tests passing). Stage 1 complete.

Stage 2 — Web application operational hardening¶

Objective¶

Improve operator consistency, predictability, and usability after writes.

Branches¶

feat/post-write-consistency
feat/publishing-ux-hardening

Stage 2A — Post-write consistency hardening ✅ COMPLETE¶

Merged feat/post-write-consistency → main at 7acff83 (2026-04-11). Added _refreshSelection() to ProductPublishingController to preserve/refresh selection after all write-triggered reloads. 11 new post-write consistency tests added (234 total feature_wordpress tests passing).

Stage 2B — Publishing workflow UX hardening ✅ COMPLETE¶

Merged feat/publishing-ux-hardening → main at b81016d (2026-04-11). Added inline validation error messages for all four single-field edits (name, price, description, category), disabled text fields and save buttons during isUpdating, and appended error detail to failure snack bars. 13 new tests added (247 total feature_wordpress tests passing). Stage 2 complete.

Stage 3 — Web application operator efficiency¶

Objective¶

Increase throughput for product triage and management using existing data.

Branches¶

feat/multi-select-groundwork
feat/list-efficiency-improvements

Stage 3A — Multi-select groundwork (read/state only first) ✅ COMPLETE¶

Merged feat/multi-select-groundwork → main (2026-05-22). Added multi-selection state to ProductPublishingController (toggleMultiSelect, clearMultiSelection, selectAllVisible, isMultiSelected, multiSelectedIds, multiSelectedCount). Updated ProductDraftCard with optional leading checkbox for multi-select mode. Added _MultiSelectBar to ProductPublishingPage with selected-count display, Select All, and Clear actions. Single-item preview selection preserved independently. 15 new multi-select tests added (262 total feature_wordpress tests passing). No bulk writes introduced.

Stage 3B — List efficiency improvements ✅ COMPLETE¶

Merged feat/list-efficiency-improvements → main (2026-05-22). Added compact/standard view toggle (ListDensity enum), staleness detection (isStale(), staleCount() with 30-day threshold), keyboard navigation (selectNextDraft/selectPreviousDraft with wrapping), description snippet in standard card, and stale indicator icon. Updated ProductDraftCard with compact two-row layout variant and Flexible overflow handling. Page wires up Focus+onKeyEvent for arrow keys and density toggle button. 32 new tests added (294 total feature_wordpress tests passing). Stage 3 complete.

Stage 4 — Platform foundations and cross-platform readiness¶

Objective¶

Strengthen the shared platform infrastructure before expanding to Android. This stage implements the key recommendations from the codebase analysis to reduce technical debt, prevent duplication, and establish quality gates.

Key principle¶

Invest in shared foundations now so that the Android expansion (Stage 5) and all future feature work benefits from a mature design system, shared composition patterns, automated CI/CD, and proper test coverage tracking.

Branches¶

feat/design-system-shared-widgets
feat/flutter-cicd
feat/shared-composition-pattern

Merged feat/design-system-shared-widgets → main (2026-05-22). Migrated EmptyStatePanel, SectionHeader, and SummaryCard from kell_web/lib/shell/widgets/ into design_system as KcEmptyState, KcSectionHeader, and KcSummaryCard. Added KcTypography shared typography scale, KcBreakpoints responsive layout breakpoint utilities, KcLoadingState and KcErrorState shared state widgets. Updated kell_web dashboard to use design_system widgets directly; shell widget files now contain backward-compatible typedefs. Theme updated to use KcTypography.applyKcTypography(). 41 new design_system tests added (41 total design_system tests, 294 feature_wordpress tests, 24 kell_web tests — all passing). Analyze clean.

Stage 4B — Cross-platform shell composition strategy ✅ COMPLETE¶

Merged feat/shared-composition-pattern → main at 0a0abc2 (2026-05-22). Extracted shared composition abstractions into core package: KcAppConfig, KcAppEnvironment, KcAppServices (abstract), KcServiceFactory<T>, KcBootstrap, KcAppScope<T>. Updated kell_web to delegate to shared types via backward-compatible typedefs (AppConfig, AppEnvironment, AppServices, AppScope, Bootstrap). Contract for new app targets documented in kell_creations_apps/docs/composition-strategy.md. kell_web runtime behavior unchanged. 20 core tests added covering all composition abstractions (20/20 core, 41/41 design_system, 294/294 feature_wordpress, 24/24 kell_web — all passing). Analyze clean.

Stage 4C — Flutter CI/CD pipeline ✅ COMPLETE¶

Merged feat/flutter-cicd → main (2026-05-22). Added Forgejo Actions workflows: flutter-analyze.yml (runs dart analyze --fatal-infos on all 8 packages/apps) and flutter-test.yml (runs flutter test per package with per-package pass/fail count and aggregate summary table). Workflows trigger on PRs to main and all non-main branch pushes using ghcr.io/cirruslabs/flutter:stable container. Populated tools/ directory with run_all_tests.sh (local test runner with optional --analyze flag) and README.md documenting scripts and CI workflow inventory. All existing tests passing (20 core, 41 design_system, 294 feature_wordpress, 24 kell_web — 379 total). Analyze clean.

Stage 4D — Test coverage visibility ✅ COMPLETE¶

Merged feat/test-coverage-visibility → main (2026-05-22). Enhanced flutter-test.yml CI workflow to run flutter test --coverage and parse lcov.info files, producing an aggregate summary table with per-package pass/fail counts and line coverage percentages. Added collect_coverage.sh local coverage helper script and updated tools/README.md. Established baseline coverage: core 85.7% (42/49), design_system 100.0% (88/88), feature_wordpress 84.7% (857/1012), kell_web 54.1% (191/353) — overall 78.4% (1178/1502). No minimum thresholds enforced — visibility first. All 379 tests passing. Analyze clean. Stage 4 complete.

Stage 5 — Android application foundation¶

Objective¶

Bring the current operations platform capabilities to Android using shared packages first and platform-specific UI only where required.

Key principle¶

Business logic, domain logic, repositories, and feature application logic should remain shared. Android should primarily add a dedicated app shell and mobile-optimized presentation.

Branches¶

feat/android-app-shell
feat/android-publishing-surface

Stage 5A — Android app shell and bootstrap¶

Goal¶

Create the Android app entry and shell for the existing platform.

Requirements¶

add or adapt app target for Android
reuse shared packages and feature modules
preserve runtime environment selection model
ensure FAKE mode works cleanly on Android first
mobile shell/navigation should stay simple and consistent with shared app structure

Current state note¶

kell_mobile exists as a default Flutter counter template. It does not yet reference any shared packages (core, design_system, feature_*). This stage must replace the template with a proper app shell that mirrors the kell_web composition pattern (AppServices, AppScope, routing, shell).

Definition of done¶

app runs on Android emulator/device in FAKE mode
shell, navigation, and core screens render
analyze/tests remain clean
kell_mobile/pubspec.yaml references shared packages

Stage 5B — Android publishing surface¶

Goal¶

Adapt the publishing workflow for mobile form factor.

Requirements¶

reuse shared controller/use case/repository layers
optimize preview/edit interactions for smaller screens
keep feature parity for current publishing workflow where feasible
do not fork business rules for Android

Definition of done¶

Android supports browsing, filtering, status changes, and existing narrow edits
mobile presentation is usable and tested where practical

Stage 6 — Android operational maturity¶

Objective¶

Harden Android UX after the core feature surface works.

Branches¶

feat/android-feedback-polish
feat/android-mobile-ux-hardening

Stage 6A — Android feedback and action polish¶

Goal¶

Ensure action feedback patterns translate cleanly to Android.

Requirements¶

reuse shared action result model where possible
adapt SnackBar/feedback timing and presentation appropriately
validate status/edit workflows on mobile

Stage 6B — Android mobile workflow hardening¶

Goal¶

Improve ergonomics on smaller screens.

Requirements¶

verify scrolling/selection/edit flows
ensure touch targets and inline edit behavior are mobile-friendly
refine layout without changing shared domain/application contracts

Stage 7 — Controlled bulk actions (only after groundwork)¶

Objective¶

Add carefully scoped bulk operations once single-item workflows are stable across web and Android.

Branches¶

feat/bulk-status-actions
feat/bulk-operator-workflows

Entry criteria¶

Do not begin until:

single-item edit/status flows are stable
multi-select groundwork is complete
post-write consistency is hardened
Android core publishing surface exists

Candidate first bulk action¶

bulk move to draft

Explicitly defer¶

bulk generic edit
bulk category management
destructive bulk deletion unless separately justified

Suggested improvements (identified from codebase analysis)¶

This section captures structural improvements, coverage gaps, and maturity enhancements identified through codebase analysis against the architecture documentation and current implementation state. Items here are candidates for future stages or can be woven into existing stages as appropriate.

1. Stub package activation roadmap¶

The following packages exist as scaffolded stubs with no implementation. Each needs an activation plan aligned to architecture documentation:

Package	Architecture Reference	Priority	Notes
`auth`	Enterprise Identity & Access Architecture	High	No auth layer exists; all access is currently uncontrolled. Required before any multi-user or production deployment.
`data`	Enterprise Data Architecture	Medium	Shared data abstractions/caching could reduce duplication across feature repositories.
`integrations`	Enterprise Integration & Orchestration Architecture	Medium	Shared integration contracts could formalize API client patterns currently embedded in `feature_wordpress`.
`feature_finance`	Financial Analysis Components	Low	Architecture docs exist but no implementation. Defer until core WordPress/Inventory workflows mature.
`feature_mrp`	Craft Manufacturing / MRP Components	Low	Architecture docs exist but no implementation. Defer until inventory workflows mature.
`feature_social`	Social Media Management Components	Low	Architecture docs exist but no implementation. Defer until core platform stabilizes.

Recommendation: Add a Stage 8 — Infrastructure package activation to the roadmap covering auth, data, and integrations before expanding into new feature domains.

2. Design system expansion ✅ RESOLVED¶

Addressed in Stage 4A (Design system expansion and shared widget migration), merged 2026-05-22. All previously identified gaps have been resolved:

✅ Shared typography scale → KcTypography with full Material 3 hierarchy and applyKcTypography() helper

✅ Responsive layout utilities → KcBreakpoints with compact/medium/expanded/large queries and grid column helper

✅ Shared empty state, loading state, error state patterns → KcEmptyState, KcLoadingState, KcErrorState

✅ Shell widgets migrated → EmptyStatePanel, SectionHeader, SummaryCard moved from kell_web to design_system as KcEmptyState, KcSectionHeader, KcSummaryCard; backward-compatible typedefs retained in kell_web

The design_system package now contains: theme (KcColors, KcSpacing, KcTheme), typography (KcTypography), layout (KcBreakpoints), and 7 widgets (KcCard, KcStatusChip, KcEmptyState, KcSectionHeader, KcSummaryCard, KcLoadingState, KcErrorState). 41 tests, 100% line coverage.

Remaining gap: No shared button/action component library. This can be addressed in a future stage as needed.

3. Cross-platform shell composition strategy ✅ RESOLVED¶

Addressed in Stage 4B (Cross-platform shell composition strategy), merged feat/shared-composition-pattern → main at 0a0abc2 (2026-05-22). Shared composition abstractions extracted into core package: KcAppConfig, KcAppEnvironment, KcAppServices (abstract), KcServiceFactory<T>, KcBootstrap, KcAppScope<T>. kell_web updated to delegate to shared types via backward-compatible typedefs. Contract for new app targets (including kell_mobile) documented in kell_creations_apps/docs/composition-strategy.md. 20 core tests passing. Analyze clean.

4. CI/CD for Flutter applications ✅ RESOLVED¶

Addressed in Stage 4C (Flutter CI/CD pipeline), merged feat/flutter-cicd → main at 6a6323e (2026-05-22). Two Forgejo Actions workflows established: flutter-analyze.yml (runs dart analyze --fatal-infos on all 8 packages/apps) and flutter-test.yml (runs flutter test per package with aggregate summary table). Workflows trigger on PRs to main and all non-main branch pushes. Local CI helper scripts added to tools/.

Remaining gap: Flutter build validation (web + Android) is not yet automated in CI. This can be added as Android work progresses in Stage 5.

5. Test coverage visibility and quality gates ✅ PARTIALLY RESOLVED¶

Automated test count reporting and line coverage measurement now addressed in Stage 4D (test coverage visibility). CI workflow produces per-package pass/fail counts and coverage percentages. Baseline documented. Minimum threshold enforcement and trend tracking remain future enhancements.

6. Build execution tracker synchronization ✅ RESOLVED¶

The build_execution_tracker.md has been fully updated through Stage 4D. All 10 merged branches are tracked with status, dates, files changed, test counts, and analysis results. Current status correctly reflects Stage 4 complete and next branch as feat/android-app-shell (Stage 5A). Updated as part of the Stage 4C/4D merge cycle (2026-05-22).

7. Image and media management¶

Architecture documentation (traceability-index.md coverage gaps) identifies "Product image / media synchronization workflow" as a gap. The current publishing workflow handles text fields only.

Recommendation: Plan a future stage for image/media management once existing narrow edits are stable on both platforms. This aligns with the architecture gap analysis.

8. Error tracking and observability¶

No monitoring, error tracking, or analytics strategy exists for the Flutter applications. In production use:

Runtime errors are invisible unless the operator sees them
No crash reporting
No usage analytics to guide prioritization

Recommendation: Add lightweight error reporting and observability as a future stage, particularly important before any production WP-mode deployment beyond a single operator.

9. Empty tools directory ✅ RESOLVED¶

Now populated with run_all_tests.sh and README.md as part of Stage 4C (Flutter CI/CD pipeline).

10. Missing feature parity documentation ✅ PARTIALLY RESOLVED¶

A feature maturity matrix has been added to this brief (see Appendix: Feature maturity matrix at the end of this document). It maps all 12 packages across domain, application, data (fake/real), presentation, test count, and maturity level. Added 2026-05-22 during full project analysis.

Remaining gap: The matrix does not yet map architecture documentation aspirations to implementation status per feature (e.g., which architecture-described capabilities exist vs. are missing within each feature package). This can be expanded as feature packages mature.

11. Policy register CSVs are empty¶

The policy repository has 2 active governance documents (KC-POL-GOV-001, KC-PRO-GOV-001), but the register CSVs (policy-register.csv, document-control-log.csv, review-calendar.csv) contain headers only with no data rows. This means the controlled document lifecycle described in the Document Control Policy is not being followed for the governance documents themselves.

Recommendation: Populate the register CSVs with entries for the 2 active governance documents. This should be done before any additional policies are created.

12. `feature_orders` package missing standard scaffolding¶

The feature_orders package is missing standard scaffolding files (.gitignore, .metadata, CHANGELOG.md, LICENSE, README.md) that are present in all other packages. This creates inconsistency across the monorepo.

Recommendation: Add the missing files to feature_orders to match the structure of other packages. This is a low-effort, high-consistency improvement.

13. Architecture documentation shows wrong diagram¶

The Enterprise Data Architecture documentation page (docs/architecture/containers/enterprise-data-architecture.md) was referencing the wrong SVG image (showing the enterprise services diagram instead of the data architecture diagram).

Resolution: ✅ Fixed 2026-05-22 during full project analysis. Image reference corrected to enterprise-data-architecture.svg.

14. Missing diagram source references in architecture docs¶

Three architecture documentation pages were missing the standard "Diagram Source" section pointing to their PlantUML file:

docs/architecture/system-landscape.md
docs/architecture/containers/platform-containers.md
docs/architecture/components/inventory.md

Resolution: ✅ Fixed 2026-05-22 during full project analysis. Diagram source references added for consistency.

15. Empty documentation sections need initial content¶

The Standards, Integrations, and Brand documentation sections had placeholder-only index pages with no substantive content.

Resolution: ✅ Populated 2026-05-22 during full project analysis. Each section now includes current state assessment, recommendations, and actionable next steps.

16. ADR index needs retroactive entries¶

The Architecture Decision Record (ADR) index exists but contained no entries. Seven significant architecture decisions are already in effect across the platform.

Resolution: ✅ Populated 2026-05-22 during full project analysis. Seven candidate ADRs documented with status, context, decision, and consequences.

Required development workflow for every slice¶

For every branch/stage:

Start from latest main.
Inspect first.
Write a brief inspection report.
Propose the smallest implementation plan.
Implement only the current slice.
Run targeted tests.
Run flutter analyze or dart analyze as appropriate.
Summarize changed files and validation results.
Open PR into main.
Merge only after clean review and validation.
Update this brief and the build execution tracker after merge.

Standard Cline operating prompt¶

Use this at the start of any new slice:

Continue the Kell Creations Flutter operations platform workstream from current main.

Read docs/development/master_development_brief.md first and follow it as the authoritative planning document.

Constraints:
- Preserve strict package boundaries.
- Fake repositories remain in feature packages.
- Real integrations are incremental alongside fake ones.
- Runtime selection stays via --dart-define, not settings UI.
- No credentials hardcoded or committed.
- Do not broaden into generic product editing prematurely.
- Keep WooCommerce details inside the WP repository layer.
- Use small, reviewable steps only.
- Work is being driven through Cline in Windows 11 VS Code.

Working rules:
1. Inspect first. Do not edit immediately.
2. Summarize current relevant state from main.
3. Propose the smallest implementation plan for the requested slice.
4. Implement only that slice.
5. Add/update focused tests.
6. Run validation.
7. Report changed files and validation results.
8. Update master_development_brief.md and build_execution_tracker.md after merge.

Appendix: Feature maturity matrix¶

Package	Domain Layer	Application Layer	Data (Fake)	Data (Real)	Presentation	Tests	Maturity
`feature_wordpress`	✅ Complete	✅ Complete	✅ Complete	✅ WooCommerce	✅ Complete	294	Production-ready
`feature_inventory`	✅ Complete	✅ Complete	✅ Complete	❌ None	✅ Complete	Minimal	Fake-only MVP
`feature_orders`	✅ Complete	✅ Complete	✅ Complete	❌ None	✅ Complete	Some	Fake-only MVP
`feature_policy`	✅ Complete	✅ Complete	✅ Complete	❌ None	✅ Complete	Minimal	Fake-only MVP
`feature_finance`	❌ Stub	❌ Stub	❌ Stub	❌ None	❌ Stub	None	Scaffolded only
`feature_mrp`	❌ Stub	❌ Stub	❌ Stub	❌ None	❌ Stub	None	Scaffolded only
`feature_social`	❌ Stub	❌ Stub	❌ Stub	❌ None	❌ Stub	None	Scaffolded only
`auth`	❌ Stub	❌ Stub	❌ Stub	❌ None	N/A	None	Scaffolded only
`data`	❌ Stub	N/A	N/A	❌ None	N/A	None	Scaffolded only
`integrations`	❌ Stub	N/A	N/A	❌ None	N/A	None	Scaffolded only
`design_system`	N/A	N/A	N/A	N/A	✅ Expanded (theme, typography, layout, 7 widgets)	41	Foundation ready
`core`	✅ Partial	✅ Composition	N/A	N/A	N/A	20	Foundation ready

Kell Creations Operations Platform — Master Development Brief¶

Recommended repo location¶

Purpose¶

Working model¶

Current confirmed baseline on main¶

Platform structure¶

Product publishing workflow already landed on main¶

Current narrow edit capabilities on main¶

Latest known validation state on main¶

Baseline test coverage (established 2026-05-22)¶

Next recommended branch¶

Non-negotiable architectural constraints¶

Development stages¶

Stage 1 — Web application completion: controlled product editing¶

Objective¶

Branching model¶

~~Stage 1A — Description-only product edit~~ ✅ COMPLETE¶

~~Stage 1B — Category-only product edit~~ ✅ COMPLETE¶

Stage 2 — Web application operational hardening¶

Objective¶

Branches¶

~~Stage 2A — Post-write consistency hardening~~ ✅ COMPLETE¶

~~Stage 2B — Publishing workflow UX hardening~~ ✅ COMPLETE¶

Stage 3 — Web application operator efficiency¶

Objective¶

Branches¶

~~Stage 3A — Multi-select groundwork (read/state only first)~~ ✅ COMPLETE¶

~~Stage 3B — List efficiency improvements~~ ✅ COMPLETE¶

Stage 4 — Platform foundations and cross-platform readiness¶

Objective¶

Key principle¶

Branches¶

~~Stage 4A — Design system expansion and shared widget migration~~ ✅ COMPLETE¶

~~Stage 4B — Cross-platform shell composition strategy~~ ✅ COMPLETE¶

~~Stage 4C — Flutter CI/CD pipeline~~ ✅ COMPLETE¶

~~Stage 4D — Test coverage visibility~~ ✅ COMPLETE¶

Stage 5 — Android application foundation¶

Objective¶

Key principle¶

Branches¶

Stage 5A — Android app shell and bootstrap¶

Goal¶

Requirements¶

Current state note¶

Definition of done¶

Stage 5B — Android publishing surface¶

Goal¶

Requirements¶

Definition of done¶

Stage 6 — Android operational maturity¶

Objective¶

Branches¶

Stage 6A — Android feedback and action polish¶

Goal¶

Requirements¶

Stage 6B — Android mobile workflow hardening¶

Goal¶

Requirements¶

Stage 7 — Controlled bulk actions (only after groundwork)¶

Objective¶

Branches¶

Entry criteria¶

Candidate first bulk action¶

Explicitly defer¶

Suggested improvements (identified from codebase analysis)¶

1. Stub package activation roadmap¶

~~2. Design system expansion~~ ✅ RESOLVED¶

~~3. Cross-platform shell composition strategy~~ ✅ RESOLVED¶

~~4. CI/CD for Flutter applications~~ ✅ RESOLVED¶

5. ~~Test coverage visibility and quality gates~~ ✅ PARTIALLY RESOLVED¶

~~6. Build execution tracker synchronization~~ ✅ RESOLVED¶

7. Image and media management¶

8. Error tracking and observability¶

9. ~~Empty tools directory~~ ✅ RESOLVED¶

~~10. Missing feature parity documentation~~ ✅ PARTIALLY RESOLVED¶

11. Policy register CSVs are empty¶

12. feature_orders package missing standard scaffolding¶

13. Architecture documentation shows wrong diagram¶

14. Missing diagram source references in architecture docs¶

15. Empty documentation sections need initial content¶

Current confirmed baseline on `main`¶

Product publishing workflow already landed on `main`¶

Current narrow edit capabilities on `main`¶

Latest known validation state on `main`¶

Stage 1A — Description-only product edit ✅ COMPLETE¶

Stage 1B — Category-only product edit ✅ COMPLETE¶

Stage 2A — Post-write consistency hardening ✅ COMPLETE¶

Stage 2B — Publishing workflow UX hardening ✅ COMPLETE¶

Stage 3A — Multi-select groundwork (read/state only first) ✅ COMPLETE¶

Stage 3B — List efficiency improvements ✅ COMPLETE¶

Stage 4A — Design system expansion and shared widget migration ✅ COMPLETE¶

Stage 4B — Cross-platform shell composition strategy ✅ COMPLETE¶

Stage 4C — Flutter CI/CD pipeline ✅ COMPLETE¶

Stage 4D — Test coverage visibility ✅ COMPLETE¶

2. Design system expansion ✅ RESOLVED¶

3. Cross-platform shell composition strategy ✅ RESOLVED¶

4. CI/CD for Flutter applications ✅ RESOLVED¶

5. Test coverage visibility and quality gates ✅ PARTIALLY RESOLVED¶

6. Build execution tracker synchronization ✅ RESOLVED¶

9. Empty tools directory ✅ RESOLVED¶

10. Missing feature parity documentation ✅ PARTIALLY RESOLVED¶

12. `feature_orders` package missing standard scaffolding¶