Skip to main content

Feature Status Doc Template

This template is used for feature-focused, current-state documentation across:

  • @attunelogic-api
  • @attunelogic-service
  • @attunelogic-mobile

Every feature-status doc should describe what is implemented today, not the ideal future design.

1. Overview​

  • Feature name: (e.g., “Trucking Jobs/Loads & Legs”)
  • Primary users: (dispatcher, driver, technician, back office, etc.)
  • Industries: (trucking, service/repair, both)
  • What this feature solves today:
    • Short, business-focused description.

2. Repos & Entry Points​

List the main touchpoints per repo:

  • API (@attunelogic-api):
    • Models: Job, Leg, other related schemas.
    • Controllers/services: key files/functions.
    • Routes: main endpoints and URL patterns.
  • Web (@attunelogic-service):
    • Pages/layouts: main routes and screens.
    • Components/hooks: important building blocks.
    • Any relevant configuration or constants.
  • Mobile (@attunelogic-mobile):
    • Screens/features: main routes and views.
    • Components/hooks: e.g., cards, lists, forms.
    • RTK Query slices: key API hooks.

3. Current Implementation (By Platform)​

Describe how the feature behaves today, per platform.

3.1 Backend API​

  • Data model:
    • Key fields and relationships.
  • Core behaviors:
    • How records are created/updated/read.
    • Important business rules (e.g., status transitions).
  • Security & tenancy:
    • How parentCompany, appType, and roles affect behavior.

3.2 Web App (Service)​

  • User flows:
    • How a user starts and completes this workflow.
  • Key screens:
    • Important list/detail/edit views.
  • Notable UX details:
    • Validations, edge cases, feature flags, etc.

3.3 Mobile App​

  • User flows:
    • How the feature appears to drivers/technicians.
  • Key screens:
    • Primary screens/cards/components involved.
  • Offline/online behavior (if applicable).

4. Status & Completeness​

Summarize what works and what is partial.

  • Implemented today:
    • Bullet list of behaviors that are production-ready.
  • Partial / early implementations:
    • Behaviors that work only in some contexts or are fragile.
  • Missing / not implemented:
    • Important roadmap items that do not exist yet in code.

5. Dependencies & Configuration​

  • Feature flags / customer config:
    • Which customer-configs fields or settings control this feature.
  • Industry / appType:
    • How appType (trucking, serviceRepair) or operation type changes behavior.
  • Roles / permissions:
    • Required roles or permissions to access/modify this feature.

6. UX Notes & Known Issues​

  • What users experience today:
    • Helpful notes for product and support (e.g., “dispatcher must refresh to see updates”).
  • Known rough edges:
    • Confusing flows, terminology mismatches, performance issues.
  • Workarounds:
    • Any known “do this instead” guidance when users hit limits.

7. Roadmap Alignment​

Connect current state to the master roadmaps.

  • Relevant roadmap sections:
    • Links or references into MASTER_ROADMAP.md for API, Service, and Mobile.
  • What’s planned vs what exists:
    • Short comparison of planned features vs implemented ones.

8. Testing & Risk​

  • Tests:
    • Notable unit/integration/e2e tests that cover this feature.
    • Any key test utilities or fixtures.
  • Risks / edge cases:
    • Common failure modes or tricky scenarios.
  • Monitoring:
    • Any metrics/logs that help observe this feature in production.

When creating a new Feature Status doc, use these headings and focus on:

  • Being truthful about current behavior.
  • Linking to existing docs instead of duplicating detailed API docs.
  • Calling out gaps and rough edges so product/dev can prioritize improvements.