@produtype/core 0.83.1 → 0.84.1

package/dist/analyzer/detectGame.js

@@ -102,6 +102,14 @@ async function detectEngine(ctx) {
         evidence.push({ type: 'note', value: `asset pipeline script "${name}"` });
     }
     const conclusive = engineDeps.length > 0 || engineFiles.length > 0;
+    /**
+     * Whether the game ships as a binary rather than as a page.
+     *
+     * `ENGINE_FILES` are the project files of engines that build an executable — Godot,
+     * Unreal, Unity, LÖVE — and `ENGINE_DEPS` are the ones that run in a browser. The
+     * difference decides whether questions about HTTP caching mean anything here at all.
+     */
+    const nativeEngine = engineFiles.length > 0 && engineDeps.length === 0;
     /**
      * How much a project looks like a game without proving it.
      *
@@ -124,6 +132,7 @@ async function detectEngine(ctx) {
         details: {
             engines: engineDeps,
             engineFiles,
+            nativeEngine,
             supporting,
             frameLoop: loops.length > 0,
             realtime,
@@ -171,7 +180,25 @@ async function detectStatePersistence(ctx) {
      * memory, written nowhere, gone when the operating system reclaims the process.
      */
     const deviceStore = await (0, localStores_1.readLocalStores)(ctx, 3);
-    const onDevice = deviceStore.dependencies.length > 0 || deviceStore.uses.length > 0;
+    /**
+     * Where a game that is not in a browser writes a save.
+     *
+     * `localStorage` is the browser's, and the engines each have their own: `PlayerPrefs`
+     * and `Application.persistentDataPath` are Unity's, `love.filesystem` is LÖVE's,
+     * `FileAccess` and `ConfigFile` are Godot's. Every one is the name its engine
+     * defines, so a call to it is the capability rather than a word that tends to
+     * accompany it.
+     */
+    const engineSaves = await (0, textSearch_1.searchInFiles)(ctx.root, ctx.files.source, [
+        /PlayerPrefs\s*\.\s*(Set|Get)/,
+        /Application\s*\.\s*persistentDataPath/,
+        /love\s*\.\s*filesystem\s*\.\s*(write|read|newFile)/,
+        /\bConfigFile\s*\.\s*new\s*\(|\bFileAccess\s*\.\s*open\s*\(/,
+    ], 3);
+    for (const hit of engineSaves) {
+        evidence.push({ type: 'snippet', value: hit.snippet, file: hit.file, line: hit.line });
+    }
+    const onDevice = deviceStore.dependencies.length > 0 || deviceStore.uses.length > 0 || engineSaves.length > 0;
     const durable = serverStore || onDevice;
     if (serverStore)
         evidence.push({ type: 'note', value: 'a durable store is present' });

package/dist/expectations/evaluateExpectations.js

@@ -211,6 +211,24 @@ function deriveStatus(analysis, capability) {
                 return 'partial';
             return 'missing';
         }
+        /**
+         * A question about HTTP caching, asked of a game that ships as a binary.
+         *
+         * `Cache-Control`, `_headers` and `vercel.json` are how a browser is told to keep
+         * the assets, and every one of the five game fixtures — Unity, LÖVE and three web
+         * ones alike — was told at `high` that it has none. For the native two there is no
+         * browser to tell: the assets are inside the executable the player downloaded
+         * once. The capability is written for one delivery medium and was required of
+         * both.
+         *
+         * `not_applicable` rather than `unknown`: this is not a question that went
+         * unasked, it is one that does not arise.
+         */
+        case 'app.asset-delivery': {
+            if (detector(analysis, 'game.engine')?.details?.nativeEngine === true)
+                return 'not_applicable';
+            return detector(analysis, 'app.assetDelivery')?.present ? 'present' : 'missing';
+        }
         case 'jobs.background': {
             return detector(analysis, 'jobs.background')?.present ? 'present' : 'missing';
         }

package/dist/report/types.d.ts

@@ -114,6 +114,19 @@ export interface ProductionReadinessReport {
     findingsByCategory: Record<Category, Finding[]>;
     criticalIssues: Finding[];
     warnings: Finding[];
+    /**
+     * The observed rules that passed. Not the capabilities a profile asked for and found.
+     *
+     * Those live in `productProfile.capabilities`, every one of them, with its own
+     * status — and they are deliberately not repeated here. A met expectation and the
+     * observed rule underneath it are the same verification stated twice: counting both
+     * made "basic web security: 4 checks verified" read as 7.
+     *
+     * Written down because the shape misleads on the way in. Reading `findings` and
+     * `passedChecks` and finding no capability in either looks exactly like a capability
+     * no project ever satisfies, and it is not: it is the wrong array. That reading was
+     * made twice while surveying this analyzer's own corpus.
+     */
     passedChecks: Finding[];
     suggestedNextSteps: string[];
     technicalEvidence: Array<{

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@produtype/core",
-  "version": "0.83.1",
+  "version": "0.84.1",
   "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": {