Part of #517.
Context
localhost:3000 is the wrong default for most real work. A product usually wants the dotNS identity it ships under, peopl.<tld> for the network being targeted, so that accounts, storage and permissions match the deployed product rather than a local origin.
The manifest already carries that identity: LocalProductConfig.productName is the product's dotNS base name (see docs/rfcs/product-manifest.md). The CLI should read it instead of making the developer repeat it on the command line.
Required behavior
- The CLI reads the product's local manifest config from the working directory and uses
productName as the product id.
- The top-level domain follows the selected
--network, so one manifest serves .dot, .paseo and .test runs.
--product-id still overrides the manifest.
- The local-origin default applies only when no manifest is found.
- Startup output names the product id and where it came from: manifest, flag, or origin default.
Related: #515, which asks for the same thing from the host side ("i can open localhost:3000 from any host and it is peopl.dot for truapi").
Part of #517.
Context
localhost:3000is the wrong default for most real work. A product usually wants the dotNS identity it ships under,peopl.<tld>for the network being targeted, so that accounts, storage and permissions match the deployed product rather than a local origin.The manifest already carries that identity:
LocalProductConfig.productNameis the product's dotNS base name (seedocs/rfcs/product-manifest.md). The CLI should read it instead of making the developer repeat it on the command line.Required behavior
productNameas the product id.--network, so one manifest serves.dot,.paseoand.testruns.--product-idstill overrides the manifest.Related: #515, which asks for the same thing from the host side ("i can open localhost:3000 from any host and it is
peopl.dotfor truapi").