FS Garage Score Card (BE) Overview

PocketBase schema and migrations for the project-level Score Card feature, built by Thanush Babu. This is a different module from FS Garage Utilisation (BE), which lives in the same repo but was built by a different contributor.

What is this?

The backend data model for FS Garage's per-project Score Card: metric categories, individual metrics, and time-series metric entries, plus the PocketBase access rules and schema docs that go with them.

Field	Value
Category	Core / Project Tracking
GitHub	fs-garage-base
Org	TeamFleetStudio
Built by	Thanush Babu (this module only - repo also contains the Utilisation module)

Source of truth

Runtime setup, env vars, and deploy steps live in the repository. Use this Fleet Docs page for knowledge-transfer context.

Knowledge Transfer Score Card

Key Features

• metric_categories collection (pbc_366275764): project (relation), name, description, display_type (kpi_card / funnel / bar_list, set on top-level categories), color, restricted (bool), sort_order, and a self-referencing parent relation for one level of subcategory nesting (added in a follow-up migration after the initial create, to avoid a circular self-reference at creation time).
• metrics collection (pbc_3017397517): category (relation), label, description, unit (count / percent / currency), aggregation (sum / latest / average), frequency (daily/weekly/monthly/quarterly/annually - exposed to the frontend as default_granularity), one target field per cadence (target_daily, target_weekly, target_monthly, target_quarterly, target_annually) plus a one-off target_custom with target_custom_start/target_custom_end dates, is_headline_kpi, is_active (archive flag), restricted, sort_order, and a momentum JSON cache field.
• metric_entries collection (pbc_724030684): metric (relation), period_start/period_end (dates), value (number), note, entered_by (relation to users). A later migration adds a DB-level period_start <= period_end constraint on top of the app-level integrity check.
• Scorecard write rules: metric_categories/metrics/metric_entries all started with a wide-open createRule/deleteRule (any authenticated user); a follow-up migration tightened create/delete to the project's owner, or a global ceo/c-suite/project-lead role - matching the listRule/viewRule/updateRule pattern already used elsewhere.
• Business-unit project type: projects.type already supported client/product; a migration added a third value, business-unit, for the Score listing's project-type filter/badge.
• Schema documentation: docs/scorecard-schema.md, docs/scorecard-flow-feasibility.md, docs/scorecard-dev-sync.md, docs/scorecard-fsa-academy-seed-data.md - originally written to reconcile the frontend's expected schema against what existed in migrations at the time; the collections above have since been fully captured as migrations, closing that gap.

For the exact formulas the frontend runs against this data (roll-up, delta, target auto-suggestion, etc.), see FS Garage Score Card - Metrics and Calculations.

Tech Snapshot

Layer	Choice
Runtime	PocketBase binary
DB	SQLite (pb_data/)
Schema	pb_migrations/*.js (source of truth)
Scope	Scorecard-only collections (metrics, metric_categories, metric_entries) + projects field additions
Default branch	development

Related Repo

Frontend: base-fs-garage-fe - see FS Garage Score Card (FE).

Same-repo, different module: FS Garage Utilisation (BE).

Quick Start

git clone https://github.com/TeamFleetStudio/fs-garage-base.git
cd fs-garage-base

Then follow Getting Started.

Next Steps

• Getting Started - Install and run locally
• Architecture - System shape and data flow
• API Reference - Collections and access rules