fix(pay-for-content-browser-use): CLI 0.14 status parse + scaffold .gitignore + content polish

[Guy-Bachar]

Summary

Migration follow-up to #1540. Four small changes across the new
01-features/08-agents-that-transact/02-use-cases/pay-for-content-browser-use/
and 06-workshops/13-AgentCore-payments/02-use-cases/pay-for-content-browser-use/ trees:

• AgentCore CLI 0.14.x compatibility — agentcore status --json now prepends an
  Update available notice and renamed agentRuntimeArn → identifier. Both
  pay_for_content_browser.py and pay_for_content_browser.ipynb now extract the
  first balanced JSON object from stdout and fall back across identifier /
  agentRuntimeArn / runtimeArn / arn. Without this fix Step 5 fails on a
  fresh CLI install.
• Service first-mention — payment_agent.py and pay_for_content_browser.py
  module docstrings now establish "Amazon Bedrock AgentCore Runtime" before
  using the abbreviated form.
• Non-prescriptive language — replaced one Ensure → Verify and softened
  one Always.
• .gitignore for the features tree — mirrors the workshops tree; keeps the
  generated payforcontent/ scaffold and CDK build artifacts untracked.

Validation

• ruff format --check and ruff check both pass on the modified .py files
• pay_for_content_browser.py ran end-to-end on AgentCore Runtime — paywall unlocked, payment recorded, observability dashboard populated
• Notebook diffed cell-by-cell against the validated .py; no functional drift

Test plan

• ruff format --check passes in CI
• ruff check passes in CI
• Reviewer can run python pay_for_content_browser.py end-to-end with a fresh CLI install (verifies CLI 0.14 fix)

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[TateLyman]

One robustness issue in the new agentcore status --json extraction: the balanced-brace scan is not string-aware, so a { or } inside a JSON string can change depth and either truncate the first object or fail to find the boundary.

Minimal repro against the current parser shape:

stdout = 'notice\n{"resources":[{"name":"PayForContent","identifier":"arn:ok","message":"upgrade notice } after JSON"}]}\nupgrade available'
# current scan stops at the `}` inside message and json.loads() sees truncated JSON

Because this path is specifically meant to tolerate non-JSON CLI notices around the payload, I would use json.JSONDecoder().raw_decode(stdout[start:]) after locating the first { or [ instead of counting braces manually. That keeps the trailing notice tolerance while letting Python handle escaped quotes/braces inside strings.

No AWS calls or payments were used for this check; this is only a parser-level readback of the PR diff.

[github-actions]

Latest scan for commit: 2cd6644 | Updated: 2026-05-27 10:06:33 UTC

Security Scan Results

Scan Metadata

• Project: ASH
• Scan executed: 2026-05-27T10:06:17+00:00
• ASH version: 3.0.0

Summary

Scanner Results

The table below shows findings by scanner, with status based on severity thresholds and dependencies:

Column Explanations:

Severity Levels (S/C/H/M/L/I):

• Suppressed (S): Security findings that have been explicitly suppressed/ignored and don't affect the scanner's pass/fail status
• Critical (C): The most severe security vulnerabilities requiring immediate remediation (e.g., SQL injection, remote code execution)
• High (H): Serious security vulnerabilities that should be addressed promptly (e.g., authentication bypasses, privilege escalation)
• Medium (M): Moderate security risks that should be addressed in normal development cycles (e.g., weak encryption, input validation issues)
• Low (L): Minor security concerns with limited impact (e.g., information disclosure, weak recommendations)
• Info (I): Informational findings for awareness with minimal security risk (e.g., code quality suggestions, best practice recommendations)

Other Columns:

• Time: Duration taken by each scanner to complete its analysis
• Action: Total number of actionable findings at or above the configured severity threshold that require attention

Scanner Results:

• PASSED: Scanner found no security issues at or above the configured severity threshold - code is clean for this scanner
• FAILED: Scanner found security vulnerabilities at or above the threshold that require attention and remediation
• MISSING: Scanner could not run because required dependencies/tools are not installed or available
• SKIPPED: Scanner was intentionally disabled or excluded from this scan
• ERROR: Scanner encountered an execution error and could not complete successfully

Severity Thresholds (Thresh Column):

• CRITICAL: Only Critical severity findings cause scanner to fail
• HIGH: High and Critical severity findings cause scanner to fail
• MEDIUM (MED): Medium, High, and Critical severity findings cause scanner to fail
• LOW: Low, Medium, High, and Critical severity findings cause scanner to fail
• ALL: Any finding of any severity level causes scanner to fail

Threshold Source: Values in parentheses indicate where the threshold is configured:

• (g) = global: Set in the global_settings section of ASH configuration
• (c) = config: Set in the individual scanner configuration section
• (s) = scanner: Default threshold built into the scanner itself

Statistics calculation:

• All statistics are calculated from the final aggregated SARIF report
• Suppressed findings are counted separately and do not contribute to actionable findings
• Scanner status is determined by comparing actionable findings to the threshold

Scanner	S	C	H	M	L	I	Time	Action	Result	Thresh
bandit	0	0	0	0	5	0	535ms	0	PASSED	MED (g)
cdk-nag	0	0	0	0	0	0	29.1s	0	PASSED	MED (g)
cfn-nag	0	0	0	0	0	0	6ms	0	PASSED	MED (g)
checkov	0	0	0	0	0	0	4.5s	0	PASSED	MED (g)
detect-secrets	0	0	0	0	0	0	854ms	0	PASSED	MED (g)
grype	0	0	0	0	0	0	45.1s	0	PASSED	MED (g)
npm-audit	0	0	0	0	0	0	169ms	0	PASSED	MED (g)
opengrep	0	0	0	0	0	0	<1ms	0	SKIPPED	MED (g)
semgrep	0	0	0	0	0	0	<1ms	0	MISSING	MED (g)
syft	0	0	0	0	0	0	2.2s	0	PASSED	MED (g)

[mvangara10]

Please update your PR