@uge/payo 2.1.2 → 2.2.0
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/README.md +33 -6
- package/dist/index.js +215 -177
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -161,7 +161,8 @@ When detection finds a manifest, you get two quick choices:
|
|
|
161
161
|
**skips anything it can't find**: no skill is created for it and it isn't
|
|
162
162
|
mentioned. The only things applied without detection are a few safe assistant
|
|
163
163
|
policies (no AI attribution in commits, task-scoped atomic commits, confirm
|
|
164
|
-
before push, verify before push,
|
|
164
|
+
before push, verify before push, gitleaks secret scan before push, confirm
|
|
165
|
+
before destructive SQL / migrations, work from `.env.example`, and DRY/modular
|
|
165
166
|
coding standards) — all shown up front and editable on the review screen. You
|
|
166
167
|
land straight on that review screen and confirm once.
|
|
167
168
|
- **Just the high-level stack** fills in the stack facts only and interviews you
|
|
@@ -232,6 +233,28 @@ if you opt in, it asks when to run — before every commit or before pushing —
|
|
|
232
233
|
agent uses it at that point to check your pending change against the relevant project
|
|
233
234
|
skills and flag anything that conflicts.
|
|
234
235
|
|
|
236
|
+
### Guardrails enforced by hooks, not just prose
|
|
237
|
+
|
|
238
|
+
Skills are guidance the assistant _should_ follow — but an agent can skip prose. So
|
|
239
|
+
when you enable a guardrail, Payo also writes the hook that makes it fire regardless:
|
|
240
|
+
|
|
241
|
+
- **A git hook (mechanical, hard block).** When you turn on the gitleaks scan or the
|
|
242
|
+
verify-before-commit/push step, Payo writes a **`lefthook.yml`** (or, if your repo
|
|
243
|
+
already uses **husky**, **pre-commit**, or native `.git/hooks`, merges into _that_
|
|
244
|
+
runner instead — never clobbering your setup). It runs `gitleaks` and your test
|
|
245
|
+
command at the stage you chose and **blocks the commit/push on failure** — for every
|
|
246
|
+
tool, and for a human typing `git`. Payo writes the config; you wire it up once with
|
|
247
|
+
`lefthook install` (Payo tells you the command; it installs nothing itself).
|
|
248
|
+
- **A native tool hook (soft confirm).** For **Claude, Cursor, and Copilot**, Payo
|
|
249
|
+
writes a `PreToolUse` hook that pops a **confirm prompt** right when the agent runs
|
|
250
|
+
`git commit` / `git push` (to run change-audit or confirm the push) or a destructive
|
|
251
|
+
query (DB-safety). It stores no state and runs no model — it just makes the prompt
|
|
252
|
+
appear so the guardrail isn't silently skipped. Tools without a soft-confirm hook
|
|
253
|
+
(Codex, Antigravity, Windsurf) are covered by the git hook above.
|
|
254
|
+
|
|
255
|
+
Both are **idempotent** — re-running Payo never duplicates a hook — and are written
|
|
256
|
+
only for the guardrails you actually enabled.
|
|
257
|
+
|
|
235
258
|
The question Payo asks — _"Which agent CLI should Payo use to generate content?"_ —
|
|
236
259
|
picks only **which installed CLI authors the content**. The output above works with
|
|
237
260
|
every skills-compatible tool regardless of that choice.
|
|
@@ -246,23 +269,27 @@ every skills-compatible tool regardless of that choice.
|
|
|
246
269
|
## What it asks about
|
|
247
270
|
|
|
248
271
|
Payo understands **30 frameworks, 29 ORMs, and 17 databases** across
|
|
249
|
-
**TypeScript/JavaScript, Python, Go, Rust, PHP, C#, Java, and Ruby** —
|
|
250
|
-
questions
|
|
272
|
+
**TypeScript/JavaScript, Python, Go, Rust, PHP, C#, Java, and Ruby** — backed by a
|
|
273
|
+
bank of **200+ stack-tailored questions** it draws from, asking only the handful
|
|
274
|
+
your stack needs. Dimensions covered:
|
|
251
275
|
|
|
252
276
|
- **Project** — type (frontend / backend / full-stack / CLI / script) and a short description
|
|
253
277
|
- **Language & framework** — plus framework-specific conventions
|
|
254
278
|
- **API** — REST, GraphQL, gRPC, tRPC
|
|
255
279
|
- **Frontend** — styling and state management, with provider-specific
|
|
256
280
|
conventions for Tailwind, shadcn/ui, and CSS Modules
|
|
257
|
-
- **Data** — database and ORM/data-layer, with naming & migration conventions
|
|
281
|
+
- **Data** — database and ORM/data-layer, with naming & migration conventions,
|
|
282
|
+
plus a guardrail requiring confirmation before destructive SQL or migrations
|
|
258
283
|
- **Auth** — approach, session strategy, RBAC, plus provider-specific
|
|
259
284
|
conventions for Clerk, Auth.js, Better Auth, and Supabase Auth
|
|
260
285
|
- **Validation & logging** — stack-appropriate libraries
|
|
261
286
|
- **Testing** — unit / integration / component / E2E and runners
|
|
262
287
|
- **Tooling** — package manager, runtime, formatter, linter
|
|
263
288
|
- **TypeScript** — `tsconfig` strictness, target, module resolution, path aliases
|
|
264
|
-
- **Conventions** — folder structure, coding standards, docs, git workflow,
|
|
265
|
-
branch-naming / commit-message style (inferred from local git history)
|
|
289
|
+
- **Conventions** — folder structure, coding standards, docs, git workflow,
|
|
290
|
+
branch-naming / commit-message style (inferred from local git history), and an
|
|
291
|
+
option to add a gitleaks secret-scan convention (scan for leaked secrets before
|
|
292
|
+
every push)
|
|
266
293
|
- **Change audit** _(optional)_ — opt into a skill that checks your pending
|
|
267
294
|
change against the project skills before commit or push
|
|
268
295
|
|