Field report: 63 skills, 2 ran — an honest ledger from a no-remote WeChat mini-program shop (plus 4 questions)

Abierto
  • ¿Algo no está bien?
#4,161 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
24/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github, typescript
Área
developer-experience

Línea de trabajo

This is a field report with four open questions about using gstack in a local WeChat mini-program workflow; it names no files or tests to start from. Read the report and the cited ETHOS §9, then review the relevant skills and their documented purpose. Done would mean the maintainers or community have addressed the questions about which skills to keep, safety reasoning, the autoplan adaptation, and trust in AI-authored gates.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Field report: 63 skills, 2 ran — an honest ledger from a no-remote WeChat mini-program shop (plus 4 questions)

Context

One-person shop: a non-coder product owner directing AI agents (Claude Code) to build a WeChat mini-program (payment flows inside). Windows, no git remote (local-only), Chinese workflow, UI via the local WeChat component ecosystem. We kept a usage ledger of the suite, audited after two days of work, and we're sharing it as a data point for Earn Its Place.

The ledger (2026-11-07 → 11-08, one project)

  • Actually ran: 2 of 63. autoplan partially (design-doc check + preamble + plan persisted; the four phases did not run — requirements were already user-approved line by line and UI is platform-native, so we rerouted to a plan-eng-review-style independent-subagent review), and plan-eng-review as a lightweight run without the preamble/decision-brief toolchain. That lightweight run surfaced 8 real pre-build issues (physically infeasible hardware feature; payment-architecture one-way door; incomplete order state machine; missing order snapshot; missing tenant isolation; sequencing risk on real payment/print integration) — all converted into design revisions before implementation. Plus /captain as the discipline source: our no-remote crew adaptation (lanes never merge; READY = branch + full SHA + tree hash + named check evidence; controller-only merge trains; mechanical READY validator) delivered 11+ lanes with zero process accidents.
  • Absorbed as text, never executed: 7 (guard family / health / retro / document-release / test-audit / verify — replaced by our own full-check gate: 281 automated tests, all-green before every merge — / gstack-upgrade pending).
  • Inapplicable: the web design line, iOS line, browser line, deploy/canary/PR lines, web benchmark — the platform is a mini-program and the repo is local-only. Browser-style QA replaced by mini-program automation plus a browser MCP.

Honest debts

  • cso never ran and the app carries payment flows. We read ETHOS §9 — safety skills don't do cost-benefit triage. Scheduled before real gateway integration; we consider it already overdue.
  • guard hooks not installed. "Pending install" with no date means never, we know.
  • Our full-check gate is AI-written; the owner cannot read code and no human has verified it. Fault-injection drills (planted bugs on a throwaway branch) are planned.

Questions

  1. For a no-remote, non-web platform, which parts of the suite would you actually keep on? Our current cut: plan reviews (eng at minimum), the captain lineage, cso, health, retro, document-release, guard — and nothing else. Is that the right cut, or are we wrong in either direction?
  2. Does §9's "safety stays on" reasoning generalize beyond careful/freeze/guard/unfreeze/cso — e.g. document-release before a real-money launch?
  3. Our autoplan reroute (prerequisites yes, phases no, eng-review-style subagent instead): defensible adaptation, or a violation we should stop rationalizing?
  4. What legitimately builds human trust in AI-authored gates for owners who cannot read the code?

Business specifics redacted. Happy to share the generic crew templates and the READY validator script.

Lenguaje dominante
TypeScript
Estrellas
139k
Forks
20.6k
Merge medio
10 h 12 min
PR fusionados (30 d)
655

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de garrytan/gstack

Todos los issues de garrytan/gstack

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.