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

Open
#4,161 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
24/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Active
Tech stack
github, typescript

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
TypeScript
Stars
139k
Forks
20.6k
Avg merge
10h 12m
Merged PRs (30d)
655

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from garrytan/gstack

All issues in garrytan/gstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.