@produtype/core 0.98.0 → 1.0.0

package/README.md

@@ -21,20 +21,33 @@ ProdKit inspects a target project and detects:
 - GDPR/privacy signals
 - Security hardening signals
 - Upload exposure signals
-- Billing/Stripe signals
+- Billing signals: payment processors declared in any manifest this reads
 - Observability/logging signals
 - Background jobs/queue signals
 - Deployment readiness signals
 
 Then it builds a structured production-readiness report with:
 
-- Overall score (0-100)
-- Maturity level (`prototype`, `early`, `partial`, `production_ready`)
+- Overall score (0-100), or `null` where too little of the repository could be read
+  to characterise it
+- Maturity level (`inconclusive`, `prototype`, `early`, `partial`, `production_ready`)
 - Findings grouped by category
 - Critical issues and warnings
 - Passed checks
 - Suggested next steps
-- Technical evidence for each finding
+- Technical evidence for each finding — a file and a line you can open, not a summary
+
+Two things the report says about its own reading, because a finding is only worth what
+the reading behind it is:
+
+- **How deeply each language was read.** A syntax tree answered the question, or a
+  keyword search did, or the language was not read at all — and the report names which,
+  per language. The optional `typescript` peer dependency decides whether JavaScript and
+  TypeScript are parsed; without it they are searched as text, and the report says so
+  rather than claiming otherwise.
+- **Which questions could not be asked.** A check whose answer depends on a reader that
+  could not run comes back `unknown`, never `passed` and never `missing`. Blindness can
+  turn a verdict into no verdict; it is not allowed to turn one into its opposite.
 
 From the report, ProdKit can also build a deterministic remediation plan with phases, task priorities, effort estimates, and test suggestions.
 
@@ -145,7 +158,11 @@ Profile warning:
 
 Inconclusive assessments:
 
-- If no stack signals and no package manifests are detected, the report is marked **inconclusive** and the score is capped at 39 (`prototype`). An unrecognized project is never scored as production ready.
+- Where nothing identifies the repository, where too few checks reach a verdict, or
+  where most of it is written in a language this cannot read, the report is marked
+  **inconclusive** and there is no score at all: `overallScore` is `null` and the
+  maturity level is `inconclusive`. It used to cap the score at 39 instead, which was
+  a number standing where an answer was missing.
 
 ## Examples
 
@@ -220,8 +237,12 @@ its own.
 ## Current limitations
 
 - Deterministic heuristics only: the AI layer is a separate package (see above)
-- Signal-based stack coverage across common Node/Python/JS frameworks + fallback
-- Signal-based detection can produce false positives/negatives
+- JavaScript and TypeScript are parsed when the optional `typescript` peer dependency is
+  installed; every other language is read as text, matched against what its frameworks
+  and its standard library define. The report states which of the two it did.
+- Signal-based detection can produce false positives and false negatives. Where a
+  reading rests on something this could not check, the answer is `unknown` rather than a
+  guess.
 - Plan output is deterministic and read-only only
 - No cloud dashboard or UI: this package is the CLI and the library
 

package/dist/analyzer/detectEnv.js

@@ -5,6 +5,7 @@ const textSearch_1 = require("../utils/textSearch");
 const lookupTables_1 = require("./structural/lookupTables");
 const secretArguments_1 = require("./structural/secretArguments");
 const readingDepth_1 = require("./readingDepth");
+const djangoSettings_1 = require("./djangoSettings");
 const WEAK_SECRET_VALUE_RE = /(changeme|your[_-]?secret|fallback-secret(?:-change-in-production)?|change[_-]in[_-]production|your_jwt_secret_key_change_in_production|local[-_]?secret|development[-_]?secret|dev[-_]?secret|not[_-]?for[_-]?production|test123|secret)/i;
 const FALLBACK_SECRET_RE = /(jwt_secret|secret_key|session_secret)\s*[:=]\s*['"][^'"]*(changeme|your[_-]?secret|fallback-secret(?:-change-in-production)?|change[_-]in[_-]production|your_jwt_secret_key_change_in_production|local[-_]?secret|development[-_]?secret|dev[-_]?secret|not[_-]?for[_-]?production|test123|secret)[^'"]*['"]/i;
 const ENV_FALLBACK_RE = /(process\.env\.(JWT_SECRET|SECRET_KEY|SESSION_SECRET)\s*(\|\||\?\?)\s*['"][^'"]*(changeme|your[_-]?secret|fallback-secret(?:-change-in-production)?|change[_-]in[_-]production|your_jwt_secret_key_change_in_production|local[-_]?secret|development[-_]?secret|dev[-_]?secret|not[_-]?for[_-]?production|test123|secret)[^'"]*['"])/i;
@@ -148,12 +149,25 @@ async function detectEnv(ctx) {
      * argue with — silence is not.
      */
     const secretSinksUnasked = (0, readingDepth_1.wentUnasked)(secretArguments, sourceFiles) && (await (0, secretArguments_1.anyFileReachesASecretSink)(ctx.root, sourceFiles));
+    /**
+     * A settings module the application does not run is not where its secret lives.
+     *
+     * pretix keeps `SECRET_KEY = "build-time-secret-key"` in `_build_settings.py`, a
+     * module named only by its packaging script, while `manage.py` and `wsgi.py` both
+     * name `pretix.settings`. That literal was the one `critical` in its report.
+     *
+     * Only applied when the entry points say something: with no `manage.py` to read,
+     * nothing is excused and the behaviour is what it was.
+     */
+    const runningSettings = await (0, djangoSettings_1.settingsModulesTheAppRuns)(ctx);
+    const isAnotherSettingsModule = (file) => runningSettings.length > 0 && (0, djangoSettings_1.looksLikeDjangoSettings)(file) && !runningSettings.includes(file);
     const weakHits = fallbackHits.filter((m) => WEAK_SECRET_VALUE_RE.test(m.snippet)
         && SECRET_ASSIGNMENT_CONTEXT_RE.test(m.snippet)
         && !namesItself(m.snippet)
         && !valueIsAnIdentifier(m.snippet)
         && !REDACTED_VALUE_RE.test(m.snippet)
-        && !isTableEntry(m));
+        && !isTableEntry(m)
+        && !isAnotherSettingsModule(m.file));
     for (const m of weakHits) {
         const hitEvidence = { type: 'snippet', value: m.snippet, file: m.file, line: m.line };
         evidence.push(hitEvidence);

package/dist/analyzer/djangoSettings.d.ts

@@ -18,3 +18,23 @@ export declare function findDjangoSettings(ctx: DetectContext): Promise<{
     file: string;
     text: string;
 } | null>;
+/**
+ * The settings module the application actually runs, named by Django's own entry points.
+ *
+ * `manage.py`, `wsgi.py` and `asgi.py` each set `DJANGO_SETTINGS_MODULE`, and that is
+ * the framework saying which configuration is the project's. Everything else called
+ * `settings` is somebody's variant: a test harness, a build-time module, a sample.
+ *
+ * pretix is the measured case. `src/pretix/_build_settings.py` holds
+ * `SECRET_KEY = "build-time-secret-key"` and is named only by `src/pretix/_build.py`,
+ * a packaging script; `manage.py` and `wsgi.py` both name `pretix.settings`. That
+ * literal was the single `critical` in pretix's report — the severity that bars a
+ * report from the top band — raised against a line that never serves a request.
+ *
+ * A name rule could not do this: `configuration_testing.py` was caught by one in
+ * 0.80.0, and `_build_settings.py` would need "build" to mean something, which it does
+ * not. The entry point is a fact, not a word.
+ */
+export declare function settingsModulesTheAppRuns(ctx: DetectContext): Promise<string[]>;
+/** Whether a path is the sort of file a Django project keeps its configuration in. */
+export declare function looksLikeDjangoSettings(file: string): boolean;

package/dist/analyzer/djangoSettings.js

@@ -1,6 +1,8 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.findDjangoSettings = findDjangoSettings;
+exports.settingsModulesTheAppRuns = settingsModulesTheAppRuns;
+exports.looksLikeDjangoSettings = looksLikeDjangoSettings;
 const readTextFileSafe_1 = require("../utils/readTextFileSafe");
 /**
  * A settings file that is Django's, rather than one that shares its name.
@@ -31,3 +33,71 @@ async function findDjangoSettings(ctx) {
     }
     return null;
 }
+/**
+ * The settings module the application actually runs, named by Django's own entry points.
+ *
+ * `manage.py`, `wsgi.py` and `asgi.py` each set `DJANGO_SETTINGS_MODULE`, and that is
+ * the framework saying which configuration is the project's. Everything else called
+ * `settings` is somebody's variant: a test harness, a build-time module, a sample.
+ *
+ * pretix is the measured case. `src/pretix/_build_settings.py` holds
+ * `SECRET_KEY = "build-time-secret-key"` and is named only by `src/pretix/_build.py`,
+ * a packaging script; `manage.py` and `wsgi.py` both name `pretix.settings`. That
+ * literal was the single `critical` in pretix's report — the severity that bars a
+ * report from the top band — raised against a line that never serves a request.
+ *
+ * A name rule could not do this: `configuration_testing.py` was caught by one in
+ * 0.80.0, and `_build_settings.py` would need "build" to mean something, which it does
+ * not. The entry point is a fact, not a word.
+ */
+async function settingsModulesTheAppRuns(ctx) {
+    const entryPoints = ctx.files.all.filter((file) => /(^|\/)(manage|wsgi|asgi)\.py$/.test(file));
+    const modules = new Set();
+    for (const file of entryPoints.slice(0, 6)) {
+        const text = await (0, readTextFileSafe_1.readTextFileSafe)(ctx.root, file);
+        if (!text)
+            continue;
+        for (const match of text.matchAll(/DJANGO_SETTINGS_MODULE["'\s,]+["']([\w.]+)["']/g)) {
+            modules.add(match[1]);
+        }
+    }
+    if (modules.size === 0)
+        return [];
+    const paths = [];
+    for (const module of modules) {
+        const asPath = module.replace(/\./g, '/');
+        for (const file of ctx.files.all) {
+            if (file.endsWith(`${asPath}.py`) || file.endsWith(`${asPath}/__init__.py`))
+                paths.push(file);
+        }
+    }
+    /**
+     * A settings package is loaded whole, through its own imports.
+     *
+     * `config.settings.production` starts with `from .base import *`, so `base.py` is as
+     * much the running configuration as the module named. The first version of this rule
+     * excused `base.py` and a fixture written for exactly that shape — a `SECRET_KEY =
+     * "changeme"` in the base module — went from `missing` to `passed` in the corpus
+     * diff, which is how the mistake surfaced within a minute of making it.
+     *
+     * Every module beside the named one, inside a directory called `settings`, counts.
+     * That is the shape of a split configuration, and it does not reach a sibling of a
+     * plain `settings.py` — which is where pretix keeps the build-time module this rule
+     * exists to exclude.
+     */
+    const withSiblings = new Set(paths);
+    for (const file of paths) {
+        const directory = file.slice(0, file.lastIndexOf('/'));
+        if (!/(^|\/)settings$/.test(directory))
+            continue;
+        for (const candidate of ctx.files.all) {
+            if (candidate.startsWith(`${directory}/`) && candidate.endsWith('.py'))
+                withSiblings.add(candidate);
+        }
+    }
+    return [...withSiblings];
+}
+/** Whether a path is the sort of file a Django project keeps its configuration in. */
+function looksLikeDjangoSettings(file) {
+    return /(^|\/)[\w-]*settings[\w-]*\.py$/i.test(file) || /(^|\/)settings\/[\w-]+\.py$/i.test(file);
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@produtype/core",
-  "version": "0.98.0",
+  "version": "1.0.0",
   "description": "Deterministic CLI and library that analyzes a web application repository and reports how far it is from production-ready for the kind of product it is meant to be.",
   "license": "MIT",
   "bin": {