Merge main into t/commerce/W-20599053-readme

Resolved conflict in packages/b2c-dx-mcp/README.md by keeping the
streamlined version from HEAD, avoiding duplicate Configuration
documentation that was already covered in the Usage section.

Author: yhsieh1

.changeset/code-bugfix.md

@@ -0,0 +1,5 @@
+---
+'@salesforce/b2c-cli': patch
+---
+
+bugfix code deploy to not require oauth unless needed

.changeset/doc-improvements.md

@@ -0,0 +1,5 @@
+---
+'@salesforce/b2c-cli': minor
+---
+
+consistent command doc structure; better auth page; online links in examples for all topics/cmds

.changeset/log-tailing-feature.md

@@ -0,0 +1,6 @@
+---
+'@salesforce/b2c-cli': minor
+'@salesforce/b2c-tooling-sdk': minor
+---
+
+Add log tailing, listing, and retrieval commands for viewing B2C Commerce instance logs. See `b2c logs` topic.

.changeset/mrt-warnings.md

@@ -0,0 +1,5 @@
+---
+'@salesforce/b2c-cli': patch
+---
+
+mrt bundle commands now relay warnings from the bundle such as out of date node versions

.claude/skills/testing/SKILL.md

@@ -18,6 +18,19 @@ This skill covers project-specific testing patterns for the B2C CLI project.
 
 ## Running Tests
 
+For coding agents (minimal output - only failures shown):
+
+```bash
+# Run tests - only failures + summary
+pnpm run test:agent
+
+# Run tests for specific package
+pnpm --filter @salesforce/b2c-tooling-sdk run test:agent
+pnpm --filter @salesforce/b2c-cli run test:agent
+```
+
+For debugging (full output with coverage):
+
 ```bash
 # Run all tests with coverage
 pnpm run test
@@ -307,6 +320,59 @@ const client = new WebDavClient(TEST_HOST, mockAuth);
 const customAuth = new MockAuthStrategy('custom-token');
 ```
 
+## Silencing Test Output
+
+Commands may produce console output (tables, formatted displays) even in tests. Use these helpers to keep test output clean.
+
+### Using runSilent for Output Capture
+
+The `runSilent` helper uses oclif's `captureOutput` to suppress stdout/stderr:
+
+```typescript
+import { runSilent } from '../../helpers/test-setup.js';
+
+it('returns data in non-JSON mode', async () => {
+  const command = new MyCommand([], {} as any);
+  // ... setup ...
+
+  // Silences any console output from the command
+  const result = await runSilent(() => command.run());
+
+  expect(result.data).to.exist;
+});
+```
+
+Use `runSilent` when:
+- Testing non-JSON output modes (tables, formatted displays)
+- The test doesn't need to verify console output content
+- You want clean test output with only pass/fail summary
+
+### When Output Verification is Needed
+
+If you need to verify console output, stub `ux.stdout` directly:
+
+```typescript
+import { ux } from '@oclif/core';
+
+it('prints table in non-JSON mode', async () => {
+  const stdoutStub = sinon.stub(ux, 'stdout');
+
+  await command.run();
+
+  expect(stdoutStub.called).to.be.true;
+});
+```
+
+### stubParse Sets Silent Logging
+
+The `stubParse` helper automatically sets `'log-level': 'silent'` to reduce pino logger output:
+
+```typescript
+// stubParse includes silent log level by default
+stubParse(command, {server: 'test.demandware.net'});
+// Equivalent to: {server: 'test.demandware.net', 'log-level': 'silent'}
+```
+
 ## Command Test Guidelines
 
 Command tests should focus on **command-specific logic**, not trivial flag verification.
@@ -445,15 +511,43 @@ pnpm run test
 open coverage/index.html
 ```
 
+## Test Helpers Reference
+
+### CLI Package (`packages/b2c-cli/test/helpers/`)
+
+| Helper | Purpose |
+|--------|---------|
+| `runSilent(fn)` | Capture and suppress stdout/stderr from command execution |
+| `stubParse(command, flags, args)` | Stub oclif's parse method with flags (includes silent log level) |
+| `createTestCommand(CommandClass, config, flags, args)` | Create command instance with stubbed parse |
+| `createIsolatedConfigHooks()` | Mocha hooks for config isolation |
+| `createIsolatedEnvHooks()` | Mocha hooks for env var isolation |
+
+### SDK Package (`packages/b2c-tooling-sdk/test/helpers/`)
+
+| Helper | Purpose |
+|--------|---------|
+| `MockAuthStrategy` | Mock authentication for API clients |
+| `stubParse(command, flags, args)` | Stub oclif's parse method (includes silent log level) |
+| `createNullStream()` | Create a writable stream that discards output |
+| `CapturingStream` | Writable stream that captures output for assertions |
+
+### SDK Test Utils (exported from package)
+
+```typescript
+import { isolateConfig, restoreConfig } from '@salesforce/b2c-tooling-sdk/test-utils';
+```
+
 ## Writing Tests Checklist
 
 1. Create test file in `test/` mirroring source structure
 2. Use `.test.ts` suffix
 3. Import from package names, not relative paths
 4. Set up MSW server for HTTP tests (avoid fake timers)
 5. Use `isolateConfig()`/`restoreConfig()` for config-dependent tests
-6. Use `pollInterval` option for polling operations
-7. Use MockAuthStrategy for authenticated clients
-8. Test both success and error paths
-9. Focus on command-specific logic, not trivial delegation
-10. Run tests: `pnpm --filter <package> run test`
+6. Use `runSilent()` for commands that produce console output
+7. Use `pollInterval` option for polling operations
+8. Use MockAuthStrategy for authenticated clients
+9. Test both success and error paths
+10. Focus on command-specific logic, not trivial delegation
+11. Run tests: `pnpm --filter <package> run test`

AGENTS.md

@@ -18,13 +18,41 @@ pnpm run build
 pnpm --filter @salesforce/b2c-cli run build
 pnpm --filter @salesforce/b2c-tooling-sdk run build
 
-# Run tests (includes linting)
-pnpm run test
-
 # Dev mode for CLI (uses source files directly)
 pnpm --filter @salesforce/b2c-cli run dev
 # or using convenience script
 ./cli
+```
+
+## Commands for Coding Agents
+
+These commands produce condensed output optimized for AI coding agents:
+
+```bash
+# Run tests (minimal output - only failures + summary)
+pnpm run test:agent
+
+# Run tests for specific package
+pnpm --filter @salesforce/b2c-cli run test:agent
+pnpm --filter @salesforce/b2c-tooling-sdk run test:agent
+
+# Lint (errors only, no warnings)
+pnpm run lint:agent
+
+# Type-check (single-line errors, no color)
+pnpm run typecheck:agent
+
+# Format check (lists only files needing formatting)
+pnpm run -r format:check
+```
+
+## Verbose Commands (Debugging/CI)
+
+Use these for detailed output during debugging or in CI pipelines:
+
+```bash
+# Run tests with full output and coverage
+pnpm run test
 
 # Run tests for specific package
 pnpm --filter @salesforce/b2c-cli run test
@@ -33,7 +61,7 @@ pnpm --filter @salesforce/b2c-tooling-sdk run test
 # Format code with prettier
 pnpm run -r format
 
-# Lint only (without tests)
+# Lint with full output
 pnpm run -r lint
 ```
 
@@ -60,6 +88,8 @@ The header is enforced by eslint via `eslint-plugin-header`. The canonical defin
 
 ## Documentation
 
+- Update docs in `./docs/` folder and relevant skills in `./plugins/b2c-cli/skills/` when updating or adding CLI commands.
+
 See [documentation skill](./.claude/skills/documentation/SKILL.md) for details on updating user guides, CLI reference, and API docs.
 
 ```bash
@@ -76,9 +106,9 @@ pnpm run docs:build
 - CLI commands have access to this logger via `this.log` method from oclif Command class
 - CLI commands can write directly to stdout/stderr if their primary purpose is to output or stream data
 
-## Table Output
+## CLI Command Development
 
-Use `createTable` from `@salesforce/b2c-tooling-sdk/cli` for tabular output. See [CLI command development skill](./.claude/skills/cli-command-development/SKILL.md) for patterns.
+See [CLI command development skill](./.claude/skills/cli-command-development/SKILL.md) for patterns.
 
 ## Claude Code Skills
 
@@ -95,27 +125,20 @@ Use `createTable` from `@salesforce/b2c-tooling-sdk/cli` for tabular output. See
 
 See [testing skill](./.claude/skills/testing/SKILL.md) for patterns on writing tests with Mocha, Chai, and MSW.
 
-Quick commands:
-```bash
-pnpm run test                                    # Run all tests
-pnpm --filter @salesforce/b2c-tooling-sdk run test  # Test specific package
-pnpm mocha "test/clients/webdav.test.ts"         # Single file (no coverage)
-```
-
 ## Changesets
 
 This project uses [Changesets](https://github.com/changesets/changesets) for version management. When making changes that affect users, create a changeset:
 
 Changeset guidelines:
 - Create a changeset for any user-facing changes (features, bug fixes); typically in new pull requests; 
-- a pull request can have multiple changesets
+- a pull request can have multiple changesets; separate files for separate changes
 - Select the appropriate semver bump: `patch` (bug fixes) or `minor` (new features)
 - This is a pre-1.0 preview release, so there are no `major` breaking change bumps yet
 - Good changesets explain:
   - WHAT the change is
   - WHY the change was made
   - HOW a consumer should update their code
-- Good changesets are brief and user-focused (not contributor); they are generally 1 line or a short paragraph for detailed changes; The content of the changeset is used in CHANGELOG and release notes.
+- Good changesets are brief and user-focused (not contributor); they are generally 1 line or two; The content of the changeset is used in CHANGELOG and release notes. You do not need to list internal implementation details or all details of commands; just the high level summary for users.
 
 create a changeset file directly in `.changeset/` with a unique filename (e.g., `descriptive-change-name.md`):
 

docs/.vitepress/config.mts

@@ -31,6 +31,7 @@ const guideSidebar = [
       { text: 'Overview', link: '/cli/' },
       { text: 'Code Commands', link: '/cli/code' },
       { text: 'Job Commands', link: '/cli/jobs' },
+      { text: 'Logs Commands', link: '/cli/logs' },
       { text: 'Sites Commands', link: '/cli/sites' },
       { text: 'WebDAV Commands', link: '/cli/webdav' },
       { text: 'ODS Commands', link: '/cli/ods' },

docs/cli/auth.md

@@ -88,85 +88,20 @@ b2c auth token | pbcopy  # macOS: copy to clipboard
 
 ## Authentication Overview
 
-The CLI supports multiple authentication methods depending on the operation.
+For complete authentication setup instructions, see the [Authentication Setup Guide](/guide/authentication).
 
-### Account Manager API Client (OAuth)
+### Quick Reference
 
-Most instance operations require an Account Manager API Client. The CLI supports two authentication methods:
+| Operation | Auth Required |
+|-----------|--------------|
+| [Code](/cli/code) deploy/watch | WebDAV credentials |
+| [Code](/cli/code) list/activate/delete, [Jobs](/cli/jobs), [Sites](/cli/sites) | OAuth + OCAPI configuration |
+| SCAPI commands ([eCDN](/cli/ecdn), [schemas](/cli/scapi-schemas), [custom-apis](/cli/custom-apis)) | OAuth + SCAPI scopes |
+| [ODS](/cli/ods), [SLAS](/cli/slas) | OAuth + appropriate roles |
+| [MRT](/cli/mrt) | API Key |
 
-| Auth Method | When Used | Role Configuration |
-|-------------|-----------|-------------------|
-| User Authentication | Only `--client-id` provided | Roles on your **user account** |
-| Client Credentials | Both `--client-id` and `--client-secret` provided | Roles on the **API client** |
+See [Configuration](/guide/configuration) for setting up credentials via environment variables or config files.
 
-```bash
-# User Authentication (opens browser for login)
-b2c ods list --client-id xxx
-
-# Client Credentials
-export SFCC_CLIENT_ID=my-client
-export SFCC_CLIENT_SECRET=my-secret
-b2c ods list
-```
-
-Used by:
-- Code management (`code list`, `code activate`, `code delete`)
-- Job operations (`job run`, `job search`, `job import`, `job export`)
-- Site operations (`sites list`)
-- ODS operations (requires `Sandbox API User` role)
-- SLAS operations (requires `SLAS Organization Administrator` or `Sandbox API User` role depending on auth method)
-
-### Basic Auth (WebDAV)
-
-WebDAV operations support Basic Auth using your Business Manager username and WebDAV access key:
-
-```bash
-export SFCC_USERNAME=my-user
-export SFCC_PASSWORD=my-webdav-access-key
-```
-
-Used by:
-- `code deploy` (file upload)
-- `code watch` (file upload)
-- `webdav` commands
-
-### MRT API Key
-
-Managed Runtime commands use a separate API key obtained from the MRT dashboard:
-
-```bash
-export SFCC_MRT_API_KEY=your-mrt-api-key
-```
-
-See [MRT Commands](./mrt#authentication) for details.
-
-### Mixed Authentication
-
-Some commands (like `code deploy` with `--reload`) require both OAuth and WebDAV access:
-
-```bash
-export SFCC_CLIENT_ID=my-client
-export SFCC_CLIENT_SECRET=my-secret
-export SFCC_USERNAME=my-user
-export SFCC_PASSWORD=my-access-key
-b2c code deploy --reload
-```
-
-### Configuration File
-
-Credentials can be stored in a `dw.json` file:
-
-```json
-{
-  "client-id": "my-client",
-  "client-secret": "my-secret",
-  "username": "my-user",
-  "password": "my-access-key"
-}
-```
-
-Use `--config` to specify a custom config file path, or `--instance` to select a named instance configuration.
-
-### Tenant Scope
-
-For ODS and SLAS operations, your API client must have tenant scope configured for the realm/organization you wish to manage. This is set up in Account Manager when creating or editing the API client.
+::: tip
+Each command page below documents its specific authentication requirements including required scopes.
+:::