@skyf0xx/hedgehog 6.3.2 → 6.3.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
package/src/registry/cores.json
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
"name": "full-stack-app",
|
|
5
5
|
"flag": "--ts-full-stack-app",
|
|
6
6
|
"package": "@skyf0xx/hedgehog-core-full-stack-app",
|
|
7
|
-
"version": "^1.0
|
|
7
|
+
"version": "^1.1.0",
|
|
8
8
|
"language": "typescript",
|
|
9
9
|
"repository": "https://github.com/skyf0xx/hedgehog-core-full-stack-app",
|
|
10
10
|
"selects_when": "The description names server-side logic across most of the app: authorization more expressive than per-object row-level security, background jobs, scheduled work or webhook receivers as the app's primary function, server-rendered or SEO-critical pages beyond an app shell, or a data model whose working set doesn't sensibly fit on a device. Persistent domain data alone is not the signal — a tracker, journal, notebook, or planner whose data fits on the user's device is pwa-app, even with sharing, accounts, or multi-device sync in scope, and even with one or two entities that must be server-authoritative. If the project has both a marketing page and a real app behind it, this is still full-stack-app: the page becomes routes inside apps/web, not a separate project."
|
|
@@ -13,7 +13,7 @@
|
|
|
13
13
|
"name": "pwa-app",
|
|
14
14
|
"flag": "--pwa-app",
|
|
15
15
|
"package": "@skyf0xx/hedgehog-core-pwa-app",
|
|
16
|
-
"version": "^1.0
|
|
16
|
+
"version": "^1.1.0",
|
|
17
17
|
"language": "typescript",
|
|
18
18
|
"repository": "https://github.com/skyf0xx/hedgehog-core-pwa-app",
|
|
19
19
|
"selects_when": "The description names an app whose data model fits on the user's device and whose reads and writes are the user's own — a tracker, journal, notebook, planner, offline reference, or utility. Offline capability or installability named explicitly is a strong signal. Sharing, collaboration, accounts, and multi-device sync do NOT disqualify a project: Dexie Cloud provides sync, authentication, and server-enforced per-object access control, so a shared list, a family calendar, or a small team's board is still this core. A small number of entities that must be server-authoritative — a points balance, a reward ledger, anything a client must not write to directly — do NOT disqualify a project either: those entities are declared --remote and backed by Supabase (Postgres + RLS + Edge Functions) behind the same repository interface, while the rest of the app stays local-first. What routes a project to full-stack-app is server-side logic across most of the app, not the presence of one or two such entities: authorization beyond row-level policies, background jobs or webhooks as the app's primary function, server-rendered pages, or a working set too large for a device."
|
|
@@ -39,7 +39,7 @@
|
|
|
39
39
|
{
|
|
40
40
|
"name": "authored",
|
|
41
41
|
"package": "@skyf0xx/hedgehog-core-authored",
|
|
42
|
-
"version": "^1.
|
|
42
|
+
"version": "^1.2.0",
|
|
43
43
|
"language": "typescript",
|
|
44
44
|
"repository": "https://github.com/skyf0xx/hedgehog-core-authored",
|
|
45
45
|
"selects_when": "Neither shipped core fits, but the description names a real artifact a Builder step would produce — just not in either shipped core's shape. This core is designed by the planner rather than chosen from a fixed set: hedgehog-planning-intake's Phase 0 elicits the drivers first, then hedgehog-core-design names the system shape, picks the stack, derives the layers, and writes .hedgehog/core.yaml. It carries the same enforcement as a shipped core — ordered layers, scoped file access, verification before completion — but the sequence is designed for this project rather than battle-tested across many. This is the core most often confused with adopted: authored designs a workspace from scratch for a project being built new, while adopted brings Hedgehog's discipline to a repo that already exists — route here only when there is no existing codebase this work is being added to."
|
|
@@ -47,7 +47,7 @@
|
|
|
47
47
|
{
|
|
48
48
|
"name": "adopted",
|
|
49
49
|
"package": "@skyf0xx/hedgehog-core-adopted",
|
|
50
|
-
"version": "^1.
|
|
50
|
+
"version": "^1.1.0",
|
|
51
51
|
"language": "typescript",
|
|
52
52
|
"repository": "https://github.com/skyf0xx/hedgehog-core-adopted",
|
|
53
53
|
"selects_when": "The description is about bringing Hedgehog's discipline to a codebase that already exists, rather than building something new — the repo already has real source files, or the user says so explicitly: \"adopt this repo\", \"add Hedgehog to my existing project\", \"I want scope/verify enforcement on my changes here\". Not chosen by matching a `when` paragraph the way a shipped core is: hedgehog-adopt reads the repo read-only, proposes a linear-chain .hedgehog/core.yaml whose verify commands are the repo's own, and writes only .hedgehog/ — never a workspace, never a stack migration. This is the core most often confused with authored: adopted brings discipline to an existing repo, while authored designs and scaffolds a workspace from scratch for something being built new — route here only when the work is landing on a codebase that already exists."
|