@filipebraida/adonis-function-points 0.5.0 → 0.7.0

package/README.md

@@ -13,7 +13,7 @@ node ace fp:count
 
 ```
 Unadjusted count: 46 FP
-Ruleset: afp@1.4.0
+Ruleset: afp@1.6.0
 
 type      n     FP
 ILF       2     14
@@ -34,18 +34,6 @@ GET /presenca                           EO       13    3    5
 GET /presenca/relatorio                 EO       13    3    5
 ```
 
-## Why
-
-Software factories bill by function point, and the count is manual, slow, and
-varies from counter to counter. Commercial automated counters exist for
-enterprise legacy, but **no modern framework has one** — not Laravel, not Rails,
-not AdonisJS. What those ecosystems do have (`rails stats`, `laravel-stats`,
-`adonisjs-stats`) counts classes and lines, which is a different thing.
-
-This package implements the OMG **Automated Function Points** specification,
-which defines how to automate IFPUG CPM by replacing the subjective judgements
-with deterministic rules.
-
 ## Install
 
 ```bash
@@ -53,91 +41,17 @@ npm i @filipebraida/adonis-function-points
 node ace configure @filipebraida/adonis-function-points
 ```
 
-Requires **AdonisJS 7** and **Lucid 22** (see [Support](#support)).
-
-### Or run it without installing
-
-For CI, or a one-off count on a project you do not want to touch:
+Requires **AdonisJS 7** and **Lucid 22** (see [Support](#support)). In CI, or
+for a one-off count on a project you do not want to touch, the standalone
+binary needs no install, no `.env` and no database:
 
 ```bash
 npx @filipebraida/adonis-function-points count --root ./my-app
 ```
 
-The engine itself boots nothing — it only reads files — and the standalone binary
-needs no `.env`, no database, and no install inside the analysed project. The
-`fp:*` commands declare `startApp: false` for the same reason.
-
-**In CI, prefer the standalone binary.** Not for convenience: `node ace` validates
-`start/env.ts` before it runs any command, so `node ace fp:count` fails on a
-missing environment variable that has nothing to do with counting. Measured on a
-production application, it stopped at `Missing environment variable "AUTHZ_STORE"`
-and never reached the command. A pipeline that only checks out the code has no
-secrets, and does not need them to count.
-
-The standalone binary **does not replace installing**: a project that installs the
-package keeps the `node ace fp:*` commands — which is the right front-end at a
-developer's terminal, where the `.env` is already there — and both call the same
-code, so they cannot disagree about a number.
-
-```
-adonis-function-points <command> [options]
-
-  count                    count the unadjusted function points
-  inventory                the raw facts: stores, routes, tracing coverage
-  explain <name>           why one function was counted that way
-  metrics                  density, coupling and conformance, from the same run
-  diff <previous.json>     additions / modifications / deletions, and billable FP
-  calibrate <samples.csv>  correction factors against a manual count
-
-  --root <path>            application to analyse (default: the current directory)
-  --out <path>             write the result as JSON to this path
-  --json                   print JSON instead of a table
-  --min-coverage <0..1>    fail below this tracing coverage
-```
-
-Both front-ends exit non-zero when the count cannot be produced — coverage
-below the minimum, an unreadable configuration, a saved count from a different
-ruleset — so a CI job fails instead of publishing a number nobody can defend.
-
-#### In CI
-
-Every count records what it counted, so the artefact stands on its own once it
-leaves the pipeline:
-
-```json
-"source": {
-  "app": "shop",
-  "revision": "adef4ee3…",
-  "branch": "main",
-  "dirty": false,
-  "countedAt": "2026-09-24T17:40:11.000Z",
-  "config": "/app/config/function_points.ts"
-}
-```
-
-`dirty` is the field that matters in billing: a count taken over uncommitted
-changes cannot be reproduced from any revision, and whoever receives the
-invoice is entitled to know that. `app` is the manifest name, never an absolute
-path — a path would say where your machine keeps its files and travel with
-every count you send anywhere.
-
-`fp:diff` refuses two counts of different applications, the same way it refuses
-two different rulesets, and warns when either side is dirty or when both are
-the same revision.
-
-Counting an older revision needs no checkout of your working tree and nothing
-installed in it, so a pull request is two counts and a comparison:
-
-```yaml
-- run: git worktree add ../base ${{ github.event.pull_request.base.sha }}
-- run: npx @filipebraida/adonis-function-points count --root ../base --out base.json
-- run: npx @filipebraida/adonis-function-points count --out head.json
-- run: npx @filipebraida/adonis-function-points diff base.json head.json
-```
-
-The package does not deliver the result anywhere — an artifact, a ledger
-branch, a billing endpoint and a PR comment are all yours to choose. What it
-owes you is a number that is still defensible wherever it lands.
+Both front-ends call the same code and cannot disagree about a number. Which
+one to use where, what a saved count records, and how a pull request becomes
+two counts and a comparison: [`docs/ci.md`](docs/ci.md).
 
 ## Commands
 
@@ -155,73 +69,25 @@ saved count against the current state of the application. It deliberately does
 **not** take a git ref: booting an older checkout, with possibly different
 dependencies, is a problem not worth solving.
 
-### How change is priced
-
-AEP §6.5 gives explicit anchors for added (1) and deleted (0.4). For a **modified**
-function it grades the factor from 0.25 to 1.75 through Effort Complexity
-variation, which needs cyclomatic complexity this package does not measure — so it
-defaults to 1, which overestimates, and every diff says so with the amount at
-stake.
-
-What the default leaves on the table is a distinction the tool already measures:
-
-```
-changed      87 functions   378 FP  × 1
-  type              4 functions    23 FP
-  size             38 functions   204 FP
-  implementation   45 functions   151 FP
-```
-
-`implementation` means same type, same DET, same FTR, different body — a refactor.
-On a real pair of releases that was 151 of 378 FP billed as change. Pricing it at
-full functional value is not defensible, and pricing it at a number this package
-invented would be worse, so the number comes from the contract:
-
-```ts
-export default defineConfig({
-  diff: {
-    reasonFactors: { implementation: 0.25 },
-  },
-})
 ```
+adonis-function-points <command> [options]
 
-### `fp:metrics` — the counterweight
-
-If function points pay, the team optimises function points: more models, more
-endpoints, less reuse. So density and coupling are reported from the **same**
-inventory, and this command exists to put them on the same page as the number.
+  count                    count the unadjusted function points
+  inventory                the raw facts: stores, routes, tracing coverage
+  explain <name>           why one function was counted that way
+  metrics                  density, coupling and conformance, from the same run
+  diff <previous.json>     additions / modifications / deletions, and billable FP
+  calibrate <samples.csv>  correction factors against a manual count
 
+  --root <path>            application to analyse (default: the current directory)
+  --out <path>             write the result as JSON to this path
+  --json                   print JSON instead of a table
+  --min-coverage <0..1>    fail below this tracing coverage
 ```
-Density
-  FP per data store:            27.0
-  transactions per data store:  5.4
-
-Conformance
-  inputs with a validator      100.0%   (30/30)
-  entry points with a handler  100.0%   (163/163)
-  data stores reached           96.7%   (29/30)
-  tracing coverage              95.1%   (15 unresolved calls)
-
-module                  FP  trans stores     I  depends on
-pedidos                211     33      8  0.60  inventores, tecnologias, users
-portal                  69     15      0  1.00  contato, documentos, inventores, ...
-inpi                    70     11      6  0.00
-
-Mutual dependencies (cycle candidates)
-  inventores <-> tecnologias
-```
-
-The denominator of the first line is the transactions that **take** input, not
-every write. Measured over every write it read 39% on a healthy application, which
-invites the conclusion that 61% of its writes are unvalidated — and they are not:
-most are workflow triggers (`POST /orders/:id/submit`) that carry nothing beyond
-the route parameter. A metric that makes the reader draw a false conclusion is
-worse than no metric.
 
-`I` is Martin's instability, `Ce / (Ca + Ce)`: 0 means everyone depends on it and
-it depends on nobody, 1 means the reverse. A module at 0 that changes often is
-where change hurts. Cycles are **reported, not scored** — what to do about one is
-the team's decision, and a number would hide it.
+Every command exits non-zero when the count cannot be produced — coverage
+below the minimum, an unreadable configuration, a saved count from a different
+rule set — so a CI job fails instead of publishing a number nobody can defend.
 
 ### `fp:explain` — the number has to be defensible
 
@@ -247,72 +113,22 @@ Path walked:
 If function points get invoiced, someone will dispute a number — and a number
 without provenance is indefensible.
 
-## Benchmark
+### `fp:metrics` — the counterweight
 
-The only reference in this project not produced by its own authors is the case
-study published in **Vazquez, Simões & Albert (2011)**, the same one used by the
-COPPE/UFRJ dissertation on the _Ligeiro_ tool (Pinel, 2012).
-
-The fixture and the reference count were frozen in their own commit **before**
-the counter was ever run against them, with the transcription choices written
-down first. Without that the independence would be illusory.
-
-|                                     | total     | vs reference |
-| ----------------------------------- | --------- | ------------ |
-| **Vazquez et al. (2011), manual**   | **46 FP** | —            |
-| **this package**                    | **46 FP** | **0%**       |
-| Ligeiro, automated (Pinel 2012)     | 52 FP     | +13%         |
-| Ligeiro, manual under its own rules | 43 FP     | −6.5%        |
-
-Eight of the ten functions match exactly. The two that do not were **predicted
-in writing before the run**, and come from the standard rather than from
-defects:
-
-- **+1** `Consulta Apontamento Diário` is an EQ in the reference; AFP §6.5.3
-  requires collapsing EQ into EO, and an EO weighs more in the same band.
-- **−1** `Apontamento c/ Justificativa`: the IFPUG manual counts 1 DET for the
-  user message, AFP does not.
-
-They cancel out, which is exactly why the total is reported alongside the
-function-by-function agreement rather than on its own.
-
-Reproduce it with `npm test` — the benchmark is
-`tests/acceptance/vazquez.spec.ts`, and the reference is
-[`tests/fixtures/apps/vazquez/REFERENCE.md`](tests/fixtures/apps/vazquez/REFERENCE.md).
-
-## Principles
-
-**Traceability.** Every counted function says where it came from: file, line,
-rule applied, origin of each DET and each FTR, and the path walked through the
-call graph. The ruleset is versioned and printed in every report — two counts
-are only comparable if the rules did not change in between.
-
-**Say "I don't know" rather than be wrong in silence.** A call the tracer cannot
-follow enters the coverage metric. If coverage falls below the configured
-threshold, the analysis **fails** instead of emitting a number that looks right.
-This is not a preference; AFP §6.5.3 requires it:
-
-> "If the transaction execution depends on code that is unknown or unavailable
-> to the automated tool, the code end point shall be cataloged and listed in the
-> generated report in order to detect and quantify the missing patterns and
-> libraries."
-
-**Shape must not change the count.** The same logical application written in
-different ways — flat MVC or module-per-domain, fat controller or action object,
-generated artefacts or none — must produce an identical number. That is the
-project's golden invariant, and it is a test
-(`tests/acceptance/golden_invariant.spec.ts`) that was written before the first
-collector.
-
-**Extensibility as a requirement.** AdonisJS imposes no code organisation — fat
-controller, action object, static service, injected service, module function,
-job. Tracing strategies are registrable, so a project with its own convention
-registers it (see [Custom code pattern](#custom-code-pattern)).
-
-**Function points are not the only number on the dashboard.** If function points
-pay, the team optimises function points: more models, more endpoints, less
-reuse. Coupling, instability and density come free from the same inventory, and
-are the counterweight.
+If function points pay, the team optimises function points: more models, more
+endpoints, less reuse. Density, coupling, instability and conformance come free
+from the same inventory and are reported beside the number — what each metric
+means and what it deliberately does not measure: [`docs/metrics.md`](docs/metrics.md).
+
+### `fp:diff` — what change is worth
+
+Additions, modifications and deletions between two saved counts, priced by the
+factors the contract names: AEP by default, or `diff: { preset: 'sisp' }` for the
+Roteiro de Métricas do SISP v3.0 (inclusão 1,00, alteração × FI 0,63, exclusão
+0,50; `factors: { changed: 0.84 }` when the contractor did not develop the function). A modification is split by **why** it changed —
+type, size, or implementation only — so a refactor is visible before it is
+billed at full value. The reasoning, and what the default leaves on the table:
+[counting-decisions §5](docs/design/counting-decisions.md#5-identity-of-a-function-across-versions-fpdiff).
 
 ## Configuration
 
@@ -332,10 +148,11 @@ export default defineConfig({
     infrastructure: ['access_tokens', 'audits'], // excluded, with the reason in the report
     externallyMaintained: ['erp_customers'], // counted as EIF instead of ILF
     business: ['chat_sessions'], // the AFP naming filter caught it by accident
+    // technicalPatterns: [...DEFAULT_TECHNICAL_PATTERNS], // replaces the filter's naming list
     ignoreEntryPoints: ['prometheus.metrics'],
   },
 
-  retStrategy: 'constant', // or 'composition'
+  dataFunctions: { grouping: 'usage' }, // 'none' keeps every table its own data function
   maxDepth: 3, // how far to follow the call graph
   messageDet: 0, // 1 restores the IFPUG confirmation-message DET
   minCoverage: 0.85, // below this, the analysis fails
@@ -391,22 +208,25 @@ over a rate limiter or an attachment variant is a real example. Without a way
 to say so, such a call stays unresolved and drags the coverage gate down.
 
 ```ts
-const limiterIsDataFree: CallResolver = {
-  name: 'login-limiter',
-  order: 1,
-  resolve: () => [],
-  ignores(call) {
-    // true means: this is mine, and it touches no data store
-    return call.getExpression().getText().startsWith('this.loginLimiter.')
+import { ignoreCalls } from '@filipebraida/adonis-function-points'
+
+export default defineConfig({
+  resolvers: {
+    call: [
+      ignoreCalls({ name: 'login-limiter', matching: /^this\.loginLimiter\./ }),
+      ignoreCalls({ name: 'attachment-variants', methods: ['getUrl', 'getVariant'] }),
+    ],
   },
-}
+})
 ```
 
-`ignores` is asked before `resolve`, in the same order, so a later and more
-generic strategy cannot follow the call into a body it has no business reading.
-It is deliberately more expensive than a list of method names to silence: the
-volume still appears in the confidence block of `fp:count`, because a silent
-drop is the worst defect this package can have — whoever writes it.
+Or, for a shape the factory does not cover, a strategy with `ignores(call)`
+returning `true` — "this is mine, and it touches no data store". `ignores` is
+asked before `resolve`, in the same order, so a later and more generic strategy
+cannot follow the call into a body it has no business reading. It stays a
+**named** strategy on purpose: the volume it declared data-free still appears in
+the confidence block of `fp:count`, because a silent drop is the worst defect
+this package can have — whoever writes it.
 
 ## Support
 
@@ -426,9 +246,12 @@ Inherited from the AFP standard itself, not from this implementation:
 - **EQ is collapsed into EO.** Telling an inquiry from an output requires
   knowing whether there is derived data or calculation, which static analysis
   cannot see. AFP mandates the collapse.
-- **RET is approximated.** What a user recognises as a logical subgroup is not
-  derivable from code. The default pins it at 1; `composition` derives it from
-  composition relations.
+- **RET comes from usage, not from the user's view.** A `hasMany`/`hasOne`
+  child that no application code addresses directly folds into its parent as a
+  RET; one that has its own queries stays its own data function. That is the
+  only signal static analysis has, and it is conservative: it groups only when
+  the code cannot see the child apart from the parent. A child hanging off two
+  parents stays apart and is reported.
 - **Confirmation and error messages** count 1 DET in a manual count and are
   invisible here — a known systematic divergence of −1 DET per transaction.
   `messageDet: 1` restores it.
@@ -436,44 +259,42 @@ Inherited from the AFP standard itself, not from this implementation:
   judgement. AFP fixes VAF = 1, and the unadjusted count is what public
   contracts in Brazil use anyway.
 - **The modification factor in `fp:diff` is 1.** AEP grades it from 0.25 to
-  1.75 using Effort Complexity, which requires cyclomatic complexity. A flat 1
-  does not discriminate — it prices a one-line fix and a rewrite the same — and
-  the report says so.
-
-  What it does discriminate is **why** a function changed, which is usually the
-  larger question:
-
-  ```
-  changed      74 functions   318 FP  × 1
-    type              1 functions     3 FP     reclassified, e.g. EO -> EI
-    size             28 functions   141 FP     DET or FTR moved
-    implementation   45 functions   174 FP     same size, different code
-  ```
-
-  On a real month of work that is 44% of the invoice coming from refactoring.
-  Whether that should be billed at full value is a contract decision, not a
-  counting one — but it has to be visible before anyone can make it.
-
+  1.75 through Effort Complexity, which needs cyclomatic complexity this package
+  does not measure. A flat 1 prices a one-line fix and a rewrite the same, and
+  the report says so with the amount at stake. What it does discriminate is
+  **why** a function changed — type, size, or implementation only — and
+  `diff.reasonFactors` prices a refactor by the contract rather than by a number
+  the tool invented. See counting-decisions §5.
 - **Schema-driven applications undercount their input.** When the fields a user
   fills live in a JSON column whose schema is stored in the database, there is
-  nothing for static analysis to read: each opaque column counts as 1 DET.
-  Measured on a production application, the effect is about 2% of the total —
-  data functions are unaffected, and only the form-submission transaction loses
-  complexity.
-
-  `fp:count` names every opaque column a transaction reaches, so the limitation
-  is visible where you read the number rather than only in a design document.
-  The way out is to declare the number rather than let the tool guess it:
-  `overrides: { 'POST /petitions': { det: 42, reason: '…' } }`. The reason is
-  required by the type, `fp:explain` prints it beside the number, and `fp:count`
-  reports what share of the total was declared — because an override is right
-  where static analysis is blind and poison as a habit. See
-  counting-decisions §8.
+  nothing for static analysis to read: the column counts as 1 DET — a floor,
+  and `fp:count` names it on every run. The way out is to declare where the
+  fields live, by origin, and the declaration reaches every function that
+  carries the column:
+
+  ```ts
+  opaque: {
+    'Survey.answers': { schemas: 'surveySchema', reason: 'the form is a JSON Schema in the seed' },
+  }
+  ```
+
+  The reason is required, `fp:explain` prints it beside the number, and
+  `fp:count` reports what share of the total came from a declaration.
+  `overrides.<fn>.det` remains for a schema that lives only in the database.
+  See counting-decisions §8.
 
 - **Only HTTP routes are collected as entry points.** An ace command that
   imports a spreadsheet and a scheduled job are transactional functions under
   IFPUG; they are out of v1.
 
+## Benchmark
+
+The only reference in this project not produced by its own authors is the case
+study in **Vazquez, Simões & Albert (2011)**: 46 FP by hand, **46 FP** here, 8 of
+10 functions exact and the two that differ predicted in writing before the run.
+How the fixture was frozen, what Ligeiro got, and why the total is more
+defensible than any single function: [`docs/benchmark.md`](docs/benchmark.md).
+
 ## References
 
 - **OMG Automated Function Points (AFP) 1.0** — ISO/IEC 19515:2019. The
@@ -495,44 +316,32 @@ Inherited from the AFP standard itself, not from this implementation:
 
 The reasoning behind the count lives with the code:
 
-- [`docs/design/architecture.md`](docs/design/architecture.md) — the thesis, the
-  layers, and what is discovered instead of configured
+- [`docs/design/architecture.md`](docs/design/architecture.md) — why the package
+  exists, its principles, the layers, and what is discovered instead of configured
 - [`docs/design/counting-decisions.md`](docs/design/counting-decisions.md) —
   each edge case, with the AFP rule that settles it
 - [`docs/design/resolvers.md`](docs/design/resolvers.md) — the catalogue of code
   patterns and how each is followed
+- [`docs/benchmark.md`](docs/benchmark.md), [`docs/ci.md`](docs/ci.md),
+  [`docs/metrics.md`](docs/metrics.md)
 
 Three further documents are kept as a **dated record** of how the design was
 arrived at, in Portuguese, and are not a reference for current behaviour:
-[`implementation-plan.md`](docs/design/implementation-plan.md) (built phase by
-phase, and what each phase found),
-[`adonisjs-variation.md`](docs/research/adonisjs-variation.md) (what varies
-between real AdonisJS applications) and
-[`external-validation.md`](docs/research/external-validation.md) (the thesis
-tested outside the sample that produced it).
+[`implementation-plan.md`](docs/design/implementation-plan.md),
+[`adonisjs-variation.md`](docs/research/adonisjs-variation.md) and
+[`external-validation.md`](docs/research/external-validation.md).
 
 ## Contributing
 
 ```bash
 pnpm install
-pnpm test              # lint + 242 tests, from source
-pnpm run typecheck
-pnpm run compile && pnpm run test:package   # the packed tarball, installed and used
+pnpm test                                    # lint + the suite, from source
+pnpm run compile && pnpm run test:package    # the packed tarball, installed and used
 ```
 
-`test:package` is separate on purpose: the suite runs from source through
-ts-exec and never loads `build/`, which is the only thing a user gets. A
-release once had every `exports` path pointing at a file the build did not
-emit, with the whole suite green.
-
-Two house rules worth knowing before opening a PR:
-
-1. **Example first.** A fixture with a known answer comes before the code. A
-   fixture written after the code tests what the code does, not what it should
-   do.
-2. **A silent drop is the worst possible defect.** Anything the tracer cannot
-   follow must land in `unresolved` with the _right_ reason, never be quietly
-   treated as a read.
+Two house rules: a fixture with a known answer comes **before** the code, and a
+silent drop is the worst possible defect. The rest is in
+[`CONTRIBUTING.md`](CONTRIBUTING.md).
 
 ## License
 

package/build/{calibration-8eV8CEix.js → calibration-DVIf8hcE.js}

@@ -1,7 +1,7 @@
 //#region src/define_config.ts
 const DEFAULTS = {
 	boundary: {},
-	retStrategy: "constant",
+	dataFunctions: { grouping: "usage" },
 	maxDepth: 3,
 	messageDet: 0
 };
@@ -12,6 +12,10 @@ function defineConfig(config) {
 		boundary: {
 			...DEFAULTS.boundary,
 			...config.boundary
+		},
+		dataFunctions: {
+			...DEFAULTS.dataFunctions,
+			...config.dataFunctions
 		}
 	};
 }
@@ -51,6 +55,39 @@ const AEP_FACTORS = {
 	unchanged: 0
 };
 /**
+* The Roteiro de Métricas de Software do SISP, v3.0 (Portaria SGD/MGI nº 3656,
+* de 2026), §7.3 "Projeto de Melhoria" — what a Brazilian public contract names
+* instead of AEP:
+*
+*   PF_MELHORIA = PF_INCLUÍDO + FI × PF_ALTERADO + 0,50 × PF_EXCLUÍDO + PF_CONVERSÃO
+*
+* where FI, the impact factor on an altered function, is 63% when the contractor
+* developed or already maintains the function, and 84% when it did not (and must
+* document it). This preset carries the 63% — a factory billing maintenance of
+* its own work — and `diff.factors: { changed: 0.84 }` is the other case.
+* PF_CONVERSÃO is data conversion, which this package does not count.
+*
+* Read from the guide's own PDF, not from memory: an earlier draft of this
+* preset said 0,50 / 0,30, and v2.0 (2012) priced exclusion at 0,40. A contract
+* binds to a revision, so the report prints which preset priced the total.
+*/
+const SISP_FACTORS = {
+	added: 1,
+	changed: .63,
+	removed: .5,
+	unchanged: 0
+};
+const FACTOR_PRESETS = {
+	aep: {
+		label: "OMG Automated Enhancement Points 1.0, §6.5",
+		factors: AEP_FACTORS
+	},
+	sisp: {
+		label: "Roteiro de Métricas de Software do SISP v3.0 §7.3, FI 63% (own maintenance); 84% otherwise",
+		factors: SISP_FACTORS
+	}
+};
+/**
 * Two counts of DIFFERENT applications compare cleanly and mean nothing.
 *
 * The ruleset guard already refuses counts produced by different rules. This
@@ -68,8 +105,9 @@ var IncomparableSourcesError = class extends Error {
 function diffCounts(from, to, options = {}) {
 	if (from.rulesetVersion !== to.rulesetVersion || from.ruleset !== to.ruleset) throw new IncomparableRulesetsError(`${from.ruleset}@${from.rulesetVersion}`, `${to.ruleset}@${to.rulesetVersion}`);
 	if (from.source && to.source && from.source.app !== to.source.app) throw new IncomparableSourcesError(from.source.app, to.source.app);
+	const preset = options.preset ?? "aep";
 	const factors = {
-		...AEP_FACTORS,
+		...FACTOR_PRESETS[preset].factors,
 		...options.factors
 	};
 	const reasonFactors = options.reasonFactors ?? {};
@@ -140,6 +178,7 @@ function diffCounts(from, to, options = {}) {
 		* an invoice, and a reader who sees that tail stops trusting the rest.
 		*/
 		billable: round2(entries.reduce((total, entry) => total + entry.function.points * factorFor(entry), 0)),
+		preset,
 		factors,
 		reasonFactors,
 		warnings
@@ -400,4 +439,4 @@ function parseSamples(csv) {
 	return samples;
 }
 //#endregion
-export { AEP_FACTORS as a, diffCounts as c, measureStructure as i, DEFAULTS as l, parseSamples as n, IncomparableRulesetsError as o, measureConformance as r, IncomparableSourcesError as s, calibrate as t, defineConfig as u };
+export { AEP_FACTORS as a, IncomparableSourcesError as c, DEFAULTS as d, defineConfig as f, measureStructure as i, SISP_FACTORS as l, parseSamples as n, FACTOR_PRESETS as o, measureConformance as r, IncomparableRulesetsError as s, calibrate as t, diffCounts as u };

package/build/commands/main.js

@@ -14,27 +14,27 @@
 const commands = [
 	{
 		commandName: "fp:inventory",
-		importer: () => import("../fp_inventory-CPtmuuke.js")
+		importer: () => import("../fp_inventory-DIjKIC9t.js")
 	},
 	{
 		commandName: "fp:metrics",
-		importer: () => import("../fp_metrics-et8F1Wvt.js")
+		importer: () => import("../fp_metrics-BpU61waG.js")
 	},
 	{
 		commandName: "fp:count",
-		importer: () => import("../fp_count-ChtblhZV.js")
+		importer: () => import("../fp_count-arGLnVlY.js")
 	},
 	{
 		commandName: "fp:explain",
-		importer: () => import("../fp_explain-DZJ--0-S.js")
+		importer: () => import("../fp_explain-aNFApwiT.js")
 	},
 	{
 		commandName: "fp:diff",
-		importer: () => import("../fp_diff-Dt7J4IWu.js")
+		importer: () => import("../fp_diff-DBBvzq5x.js")
 	},
 	{
 		commandName: "fp:calibrate",
-		importer: () => import("../fp_calibrate-DUbHiifm.js")
+		importer: () => import("../fp_calibrate-3TxGdS1b.js")
 	}
 ];
 let cache = null;

package/build/{fp_calibrate-DUbHiifm.js → fp_calibrate-3TxGdS1b.js}

@@ -1,4 +1,4 @@
-import { s as printResult, t as runCalibrate } from "./runners-DIt1G85i.js";
+import { s as printResult, t as runCalibrate } from "./runners-Dm7cWGa-.js";
 import { n as printerFor, t as __decorate } from "./decorate-D6enDn9D.js";
 import { BaseCommand, args } from "@adonisjs/core/ace";
 //#region commands/fp_calibrate.ts

package/build/{fp_count-ChtblhZV.js → fp_count-arGLnVlY.js}

@@ -1,4 +1,4 @@
-import { n as runCount, s as printResult } from "./runners-DIt1G85i.js";
+import { n as runCount, s as printResult } from "./runners-Dm7cWGa-.js";
 import { n as printerFor, t as __decorate } from "./decorate-D6enDn9D.js";
 import { BaseCommand, flags } from "@adonisjs/core/ace";
 //#region commands/fp_count.ts

package/build/{fp_diff-Dt7J4IWu.js → fp_diff-DBBvzq5x.js}

@@ -1,4 +1,4 @@
-import { r as runDiff, s as printResult } from "./runners-DIt1G85i.js";
+import { r as runDiff, s as printResult } from "./runners-Dm7cWGa-.js";
 import { n as printerFor, t as __decorate } from "./decorate-D6enDn9D.js";
 import { BaseCommand, args } from "@adonisjs/core/ace";
 //#region commands/fp_diff.ts

package/build/{fp_explain-DZJ--0-S.js → fp_explain-aNFApwiT.js}

@@ -1,4 +1,4 @@
-import { i as runExplain, s as printResult } from "./runners-DIt1G85i.js";
+import { i as runExplain, s as printResult } from "./runners-Dm7cWGa-.js";
 import { n as printerFor, t as __decorate } from "./decorate-D6enDn9D.js";
 import { BaseCommand, args } from "@adonisjs/core/ace";
 //#region commands/fp_explain.ts