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

オープン
  • 何か問題がありますか？
#4,161 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
24/100
issue の種類
ドキュメント
明瞭さ
説明が足りない
活発さ
活発
技術スタック
github, typescript
領域
developer-experience

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
139k
フォーク
20.6k
平均マージ
10時間 12分
マージ済み PR（30日）
655

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

garrytan/gstack のほかの issue

garrytan/gstack の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。