Allen One Click Script
Discover the runnable services in all project roots supplied by the user, generate or refresh a service-selection launcher, start that selector on the current machine, and turn the submitted selection into reusable one-click start and stop scripts for both Windows and macOS. Starting the selector is required; starting the generated business-service scripts is not authorized.
Locate the launcher
Prefer the current workspace when it contains services.json and launcher.py. Otherwise check whether C:\allen\服务一键启动 exists before using it. Never assume this Windows path on macOS or another machine.
Read references/project-discovery.md before scanning project roots. Read references/selector-contract.md before generating or launching the selector. Read references/known-services.md only as a discovery seed for Allen's established stack; re-scan the repositories rather than treating that file as the current inventory. Read references/script-contract.md when creating or changing generator behavior.
Bare invocation defaults
When the user invokes only $allen-one-click-script, treat it as the complete request: “扫描我的全部项目,启动服务选择器,并根据选择生成 Windows 和 macOS 一键启动脚本。” Do not ask the user to repeat that intent.
Apply these defaults unless the user overrides them:
- Project scope: every project root already supplied or attached in the current task. For Allen's established workspace, also use every existing root listed in
references/known-services.md. - Discovery: re-scan all scoped roots and refresh the complete selectable inventory before opening the selector.
- Selection: generate or refresh and visibly launch the interactive selector on the current OS.
- Output platforms: both Windows and macOS from one submitted service selection.
- Execution boundary: launch only the selector; generate the service start/stop scripts but do not run them.
- Profile name: collect it in the selector or use a safe timestamped default when the selector supports no name field.
If no project root can be resolved from the current task or the known Allen roots, ask only for the missing project path. Do not replace the scoped scan with a machine-wide filesystem search.
Required discovery-to-script flow
When the user asks to generate a one-click script:
- Resolve every project root explicitly supplied or attached by the user. A parent repository may contain many independently runnable services.
- Re-scan every root for manifests, workspace/module definitions, executable entry points, existing local-development scripts, and applicable
AGENTS.mdfiles. Do not rely only on an existingservices.jsonor a remembered service list. - Build a fresh inventory of all evidence-backed runnable services. Reconcile discovered entry points against the catalog so no verified service is silently omitted, and separate uncertain candidates from selectable services.
- Write the complete verified inventory into the selector's data source. Every verified service must be selectable; stale and ambiguous entries must not appear as normal choices.
- Generate or update current-platform wrappers for the selector and launch the selector visibly. It must support multi-select, select-all/clear, profile naming, validation, and submission. Starting this interactive selector is part of the workflow.
- After submission, validate and deduplicate the selected IDs. Reject unknown or empty selections.
- Generate both Windows and macOS artifacts by default from the same frozen selection; narrow to one platform only when the user explicitly requests it.
- Generate matching
startandstopscripts plus a profile manifest. - Verify inventory coverage, selection fidelity, manifest consistency, artifact existence, and platform syntax.
- Show the output directory, selected services, and exact usage commands for each platform. Keep the selector result visible until the user acknowledges it.
Launch the selector, not the generated service launcher. Do not automatically run a generated profile's start.cmd, start.ps1, or start.command. Do not close the selector immediately after successful generation. If the existing generator defaults to generate-and-launch, explicitly pass its no-launch option.
For the established launcher:
python launcher.py --platform both --no-launch
For the native Windows generator:
& '.\generate-windows.ps1' -NoLaunch
Use non-interactive generation only when the user already provided the service selection and does not need the selector. Do not reinterpret permission to launch the selector as permission to start services. If the current launcher cannot discover the supplied projects, expose every discovered service, or generate both platforms, update its catalog/generator before opening the selector; do not fall back to a partial fixed list without telling the user.
Discover and catalog services
Treat repository documentation and existing scripts as evidence, not as permission to deploy or connect to production systems.
Search all supplied roots, including monorepo children and workspace modules. Ignore dependency, build-output, VCS, generated-profile, and cache directories unless repository metadata explicitly identifies one as a runnable project. For each candidate service:
- Read applicable
AGENTS.md, manifests, executable entry points, and local-development documentation. - Prefer an existing documented local start command. Otherwise derive a command only when the manifest and executable entry point agree.
- Include only independently runnable processes. Exclude shared libraries, test fixtures, generated code, vendored dependencies, and modules without an executable entry point.
- Treat multiple executable modules in one repository as separate services. Treat duplicate evidence for the same working directory and entry point as one service.
- Record a stable ID, display name, project/group, project-root key, working directory, Windows command, macOS command, evidence paths, safe environment defaults, required files, runtime prerequisites, and confidence.
- Keep project roots configurable through environment variables. Never encode a Windows absolute path as the macOS default; use an override variable or a verified macOS root.
- Never copy secret values from YAML,
.env, key files, or logs into catalogs or generated scripts.
An existing catalog is a cache, not proof of completeness. Add newly discovered runnable services, update stale commands, and retain a concise reason for every excluded candidate. If a command remains ambiguous, show it under “needs confirmation” rather than silently offering an unsafe guess.
Generated script behavior
Windows scripts should:
- preflight all selected services before starting any process;
- validate project directories, executables, and required dependency files;
- resolve executables to absolute paths before spawning children;
- run background services hidden and redirect stdout/stderr to per-service logs;
- record PID, service ID, and process start time;
- prevent duplicate starts and safely reject reused PIDs during stop;
- stop each full process tree;
- keep the
start.cmdandstop.cmdresult visible until the user presses a key.
macOS scripts should use .command files, configurable project-root environment variables, executable permissions, PID records, logs, process-group-aware stopping, and a matching stop script. Shell-quote paths safely and avoid Windows-only command syntax.
Both platform outputs must represent the same service selection. A service may have platform-specific commands or prerequisites; record those explicitly in the manifest. If a selected service truly lacks support for one platform, report that before generation instead of silently omitting it from that platform's script.
The generated scripts may start services when the user later runs them. Generating the scripts must not start anything.
Selection surfaces
Prefer a local selector script when the user asks to generate and start a selection script. On Windows, open its interactive terminal or local UI visibly and allow the wrapper terminal to close only after a successful handoff to that selector. On macOS, provide and launch the corresponding .command selector. Never hide an interactive selector window that the user must control.
When the user explicitly wants to select services inside Codex, an in-conversation multi-select control may be used instead. Its action must send a follow-up containing the selected IDs, profile name, both target platforms, and the explicit phrase “generate only; do not start services.” The control itself cannot write or execute local scripts.
Persist only non-sensitive selection state. Do not put paths containing secrets, credentials, environment values, or log contents into widget state.
Dependencies and scope
- Do not install packages or SDKs merely to generate scripts. Record missing runtime prerequisites in the generated profile documentation or final report.
- Do not invent credentials, licenses, broker choices, database addresses, or cloud endpoints.
- Do not start databases, Redis, Kafka, Nacos, Docker workloads, migrations, or remote infrastructure.
- Preserve existing generated profiles, PID state, logs, and unrelated user changes.
Verification
For generator changes:
- rescan every supplied project root and compare discovered runnable entry points with the generated catalog;
- verify every freshly discovered service appears in the selector and stale/ambiguous entries do not appear as ordinary choices;
- parse the service catalog;
- run generator tests without writing bytecode into deliverables;
- parse generated PowerShell with the PowerShell parser;
- syntax-check generated
.commandfiles with a compatible shell when available; - exercise selector submission in a non-GUI test mode, requesting both platforms and no service launch;
- verify the Windows and macOS manifests contain the identical selected service IDs;
- verify that launching the selector starts only the selector process;
- verify that no service process was created during validation.
Delete only exact temporary test profiles after resolving and checking their paths. Never remove user-created profiles or logs.