feat(docs): add observability logging baseline and update related documentation across multiple languages

Author: stefaniuk

…bservability-logging-baseline.include.md …cludes/observability-baseline.include.md.github/instructions/includes/observability-logging-baseline.include.md renamed to .github/instructions/includes/observability-baseline.include.md .github/instructions/includes/observability-logging-baseline.include.md renamed to .github/instructions/includes/observability-baseline.include.md

@@ -547,26 +547,26 @@ For CLIs:
 - [PY-OBS-012] Structured logging (JSON) should be available when useful:
   - [PY-OBS-012a] `--log-format json` (or equivalent)
   - [PY-OBS-012b] `--log-level` (INFO/WARNING/ERROR/DEBUG)
-- [PY-OBS-013] When emitting structured output, include the CLI invocation fields defined in the [Structured Logging Baseline](./includes/observability-logging-baseline.include.md#2-required-fields-clis) and never log secrets, tokens, credentials, or raw personal data.
+- [PY-OBS-013] When emitting structured output, include the CLI invocation fields defined in the [Structured Logging Baseline](./includes/observability-baseline.include.md#2-required-fields-clis) and never log secrets, tokens, credentials, or raw personal data.
 - [PY-OBS-014] Prefer event-style logs with stable names:
   - [PY-OBS-014a] `command.start`, `command.end`, `step.start`, `step.end`, `dependency.call`, `dependency.error`
 
 For APIs (mandatory structured logging):
 
 Logs must be structured (prefer JSON), queryable, and consistent.
 
-- [PY-OBS-015] Service/API logs must include the required fields defined in the [Structured Logging Baseline](./includes/observability-logging-baseline.include.md#1-required-fields-services-apis); do not fork or trim that list locally.
+- [PY-OBS-015] Service/API logs must include the required fields defined in the [Structured Logging Baseline](./includes/observability-baseline.include.md#1-required-fields-services-apis); do not fork or trim that list locally.
 - [PY-OBS-016] HTTP metadata (method, path template, status code) and timing/outcome fields from the baseline are mandatory for every request log entry.
-- [PY-OBS-017] Apply the baseline secrecy rules ([section 3](./includes/observability-logging-baseline.include.md#3-sensitive-data--secrecy-rules)): never log secrets, credentials, or raw personal data; mask or truncate payloads when logging is explicitly required.
-- [PY-OBS-018] Use the baseline event taxonomy ([section 4](./includes/observability-logging-baseline.include.md#4-event-naming--taxonomy)) so request/dependency events stay searchable across repos.
+- [PY-OBS-017] Apply the baseline secrecy rules ([section 3](./includes/observability-baseline.include.md#3-sensitive-data--secrecy-rules)): never log secrets, credentials, or raw personal data; mask or truncate payloads when logging is explicitly required.
+- [PY-OBS-018] Use the baseline event taxonomy ([section 4](./includes/observability-baseline.include.md#4-event-naming--taxonomy)) so request/dependency events stay searchable across repos.
 - [PY-OBS-019] Prefer high-signal logs only:
   - [PY-OBS-019a] start/end of request (one each)
   - [PY-OBS-019b] key domain decision points (not every line)
   - [PY-OBS-019c] boundary calls (DB, AWS, HTTP)
   - [PY-OBS-019d] errors (once, with structured context)
-  - [PY-OBS-019e] When `DEBUG`/diagnostic logging is enabled, emit a single function/method entry log for every call path, capturing the operation name and a sanitised summary of arguments per the [Structured Logging Baseline §5](./includes/observability-logging-baseline.include.md#5-diagnostics--sampling); never include sensitive data.
+  - [PY-OBS-019e] When `DEBUG`/diagnostic logging is enabled, emit a single function/method entry log for every call path, capturing the operation name and a sanitised summary of arguments per the [Structured Logging Baseline §5](./includes/observability-baseline.include.md#5-diagnostics--sampling); never include sensitive data.
 
-Log level policy (see also [§5.1 of the baseline](./includes/observability-logging-baseline.include.md#51-log-level-hierarchy)):
+Log level policy (see also [§5.1 of the baseline](./includes/observability-baseline.include.md#51-log-level-hierarchy)):
 
 - [PY-OBS-020] `DEBUG`: diagnostic level that **includes trace-like function/method entry logging** (Python's stdlib `logging` lacks a distinct `TRACE` level); only for local/dev or explicitly enabled diagnostics (never required in normal production operation)
 - [PY-OBS-021] `INFO`: normal request lifecycle and major domain events

.github/instructions/python.instructions.md

@@ -199,7 +199,7 @@ For Rust CLIs, follow the [CLI Contract](./includes/cli-contract-baseline.includ
 
 ## 9. Observability 🔭
 
-For Rust services and CLIs that produce structured logs, follow the [Structured Logging Baseline](./includes/observability-logging-baseline.include.md).
+For Rust services and CLIs that produce structured logs, follow the [Structured Logging Baseline](./includes/observability-baseline.include.md).
 
 ### 9.1 Tooling
 
@@ -209,23 +209,23 @@ For Rust services and CLIs that produce structured logs, follow the [Structured
 
 ### 9.2 Required fields
 
-- [RS-OBS-004] Service/API logs must include the required fields from [§1 of the baseline](./includes/observability-logging-baseline.include.md#1-required-fields-services-apis-async-workers): `service`, `version`, `environment`, `request_id`, `operation`, `duration_ms`, and `error_code` (on failure).
-- [RS-OBS-005] CLI logs must include the required fields from [§2 of the baseline](./includes/observability-logging-baseline.include.md#2-required-fields-clis): `command`, `args` (sanitised), `exit_code`, `duration_ms`.
+- [RS-OBS-004] Service/API logs must include the required fields from [§1 of the baseline](./includes/observability-baseline.include.md#1-required-fields-services-apis-async-workers): `service`, `version`, `environment`, `request_id`, `operation`, `duration_ms`, and `error_code` (on failure).
+- [RS-OBS-005] CLI logs must include the required fields from [§2 of the baseline](./includes/observability-baseline.include.md#2-required-fields-clis): `command`, `args` (sanitised), `exit_code`, `duration_ms`.
 
 ### 9.3 Secrecy and safety
 
-- [RS-OBS-006] Apply the secrecy rules from [§3 of the baseline](./includes/observability-logging-baseline.include.md#3-sensitive-data--secrecy-rules): never log secrets, tokens, or raw personal data.
+- [RS-OBS-006] Apply the secrecy rules from [§3 of the baseline](./includes/observability-baseline.include.md#3-sensitive-data--secrecy-rules): never log secrets, tokens, or raw personal data.
 - [RS-OBS-007] Use `tracing`'s `skip` or `skip_all` in `#[instrument]` to exclude sensitive fields from spans.
 - [RS-OBS-008] When logging payloads, truncate large bodies and mark with `truncated=true`.
 
 ### 9.4 Event taxonomy
 
-- [RS-OBS-009] Use the event taxonomy from [§4 of the baseline](./includes/observability-logging-baseline.include.md#4-event-naming--taxonomy): stable names like `request.start`, `request.end`, `dependency.call`, `dependency.error`.
+- [RS-OBS-009] Use the event taxonomy from [§4 of the baseline](./includes/observability-baseline.include.md#4-event-naming--taxonomy): stable names like `request.start`, `request.end`, `dependency.call`, `dependency.error`.
 - [RS-OBS-010] Emit both start and end spans/events around expensive boundaries (HTTP calls, DB queries, filesystem IO).
 
 ### 9.5 Diagnostics
 
-- [RS-OBS-011] Default to `info` level; enable `debug`/`trace` only via explicit configuration (`RUST_LOG` or application config). Use `trace` for function/method entry logging (per [§5.1 of the baseline](./includes/observability-logging-baseline.include.md#51-log-level-hierarchy)) and `debug` for coarser diagnostic messages.
+- [RS-OBS-011] Default to `info` level; enable `debug`/`trace` only via explicit configuration (`RUST_LOG` or application config). Use `trace` for function/method entry logging (per [§5.1 of the baseline](./includes/observability-baseline.include.md#51-log-level-hierarchy)) and `debug` for coarser diagnostic messages.
 - [RS-OBS-012] Every exception must trigger exactly one `error!` log entry with `error_code` and correlation identifiers, even if the software can recover.
 - [RS-OBS-013] When `trace` level is enabled, use `#[instrument(level = "trace")]` on all public functions and async boundaries to emit function entry spans automatically.
 
@@ -281,7 +281,7 @@ Before shipping Rust code, verify:
 - [RS-CHK-008] No `unwrap()` in library code; justified only in binaries
 - [RS-CHK-009] No anti-patterns from §12 are present
 - [RS-CHK-010] Code passes `cargo fmt`, `cargo clippy`, `cargo test`, `cargo doc`
-- [RS-CHK-011] Structured logs follow the [Observability Logging Baseline](./includes/observability-logging-baseline.include.md)
+- [RS-CHK-011] Structured logs follow the [Observability Logging Baseline](./includes/observability-baseline.include.md)
 - [RS-CHK-012] CLI binaries follow the [CLI Contract](./includes/cli-contract-baseline.include.md) for exit codes and streams
 
 ---

.github/instructions/rust.instructions.md

@@ -516,7 +516,7 @@ Logging must be intentional, queryable, and safe.
 **Operational rules:**
 
 - [TF-OBS-020] Prefer structured logs (JSON) for application logs; avoid free-text-only logs.
-  - [TF-OBS-020a] Application logs emitted by Lambda functions, ECS containers, and similar compute must follow the [Structured Logging Baseline](./includes/observability-logging-baseline.include.md) field requirements — this is an infrastructure concern because log retention, parsing, and alerting depend on consistent schemas.
+  - [TF-OBS-020a] Application logs emitted by Lambda functions, ECS containers, and similar compute must follow the [Structured Logging Baseline](./includes/observability-baseline.include.md) field requirements — this is an infrastructure concern because log retention, parsing, and alerting depend on consistent schemas.
 - [TF-OBS-021] Ensure logs include correlation identifiers consistently (request id / trace id / account id / region).
 - [TF-OBS-022] Use CloudWatch Logs Insights-friendly fields and stable event names.
 

.github/instructions/terraform.instructions.md

@@ -565,7 +565,7 @@ If the system depends on external services (cloud APIs, databases, third-party s
 
 ### 11.6 Debugging modes 🪲
 
-- [TS-ERR-017] Support controlled diagnostics (see also [§5.1 of the baseline](./includes/observability-logging-baseline.include.md#51-log-level-hierarchy) for level hierarchy):
+- [TS-ERR-017] Support controlled diagnostics (see also [§5.1 of the baseline](./includes/observability-baseline.include.md#51-log-level-hierarchy) for level hierarchy):
   - [TS-ERR-017a] `--verbose` increases detail (CLIs)
   - [TS-ERR-017b] `--debug` may include stack traces and enables function/method entry logging (trace-like behaviour; still never secrets)
 - [TS-ERR-018] Diagnostics must not change behaviour, only observability.
@@ -592,11 +592,11 @@ Observability is non-negotiable.
 
 ### 12.2 Logging
 
-- [TS-OBS-004] Prefer structured logs (JSON) and follow the [Structured Logging Baseline](./includes/observability-logging-baseline.include.md) for canonical field definitions.
-- [TS-OBS-005] Service/API logs must include the required metadata from [section 1](./includes/observability-logging-baseline.include.md#1-required-fields-services-apis); do not remove or rename those fields locally.
-- [TS-OBS-006] CLI/worker logs that emit structured output must include the CLI invocation fields from [section 2](./includes/observability-logging-baseline.include.md#2-required-fields-clis).
-- [TS-OBS-007] Apply the secrecy and event taxonomy rules from [sections 3–4](./includes/observability-logging-baseline.include.md#3-sensitive-data--secrecy-rules); never log secrets or personal data, and keep event names (`request.*`, `dependency.*`, etc.) stable for automation.
-  - [TS-OBS-007a] When verbose or debug logging is enabled, emit a single function/method entry log for every call path with the operation name and a sanitised summary of arguments per [section 5](./includes/observability-logging-baseline.include.md#5-diagnostics--sampling); never include sensitive payloads.
+- [TS-OBS-004] Prefer structured logs (JSON) and follow the [Structured Logging Baseline](./includes/observability-baseline.include.md) for canonical field definitions.
+- [TS-OBS-005] Service/API logs must include the required metadata from [section 1](./includes/observability-baseline.include.md#1-required-fields-services-apis); do not remove or rename those fields locally.
+- [TS-OBS-006] CLI/worker logs that emit structured output must include the CLI invocation fields from [section 2](./includes/observability-baseline.include.md#2-required-fields-clis).
+- [TS-OBS-007] Apply the secrecy and event taxonomy rules from [sections 3–4](./includes/observability-baseline.include.md#3-sensitive-data--secrecy-rules); never log secrets or personal data, and keep event names (`request.*`, `dependency.*`, etc.) stable for automation.
+  - [TS-OBS-007a] When verbose or debug logging is enabled, emit a single function/method entry log for every call path with the operation name and a sanitised summary of arguments per [section 5](./includes/observability-baseline.include.md#5-diagnostics--sampling); never include sensitive payloads.
 
 ### 12.3 Metrics
 

.github/instructions/typescript.instructions.md

@@ -6,7 +6,7 @@ description: Evaluate and enforce specific CLI argument parsing discipline acros
 
 ## Goal 🎯
 
-Audit every CLI entrypoint and argument parser in this repository against the CLI Contract Baseline and the argument parsing standards defined below. For each entrypoint, report compliance or non-compliance per category, citing concrete evidence (function names, line numbers, code snippets). Where gaps exist, implement fixes immediately using the sensible defaults described in this prompt and the baseline.
+Review every CLI entrypoint and argument parser against the CLI standards below. Report compliance with evidence and fix gaps using the defaults in this prompt and the baseline.
 
 ## Steps 👣
 
@@ -25,21 +25,11 @@ Audit every CLI entrypoint and argument parser in this repository against the CL
 2. Flag manual parsing (`sys.argv`, `os.Args`, `process.argv`) or ad-hoc split logic that bypasses a parser.
 3. Record where validation and default handling occur.
 
-### Step 3: Assess compliance
+### Step 3: Assess CLI contract baseline compliance
 
-Evaluate each CLI against the CLI Contract Baseline at:
+Use it for context and evaluate each CLI against the CLI Contract Baseline:
 
-- `.github/instructions/includes/cli-contract-baseline.include.md`
-
-Report compliance for:
-
-- Exit codes
-- Stdout vs stderr
-- Documentation and testing expectations
-- Developer ergonomics
-- Wrappers and shared libraries
-- Cloud and serverless workloads (where relevant)
-- Argument parsing and flags
+- [.github/instructions/includes/cli-contract-baseline.include.md](../instructions/includes/cli-contract-baseline.include.md)
 
 ### Step 4: Remediate
 

.github/prompts/dev.implement-cli-args-parsing.prompt.md

@@ -6,7 +6,7 @@ description: Evaluate and enforce specific logging discipline across the codebas
 
 ## Goal 🎯
 
-Audit every Python file in this repository against the logging standards defined below. For each file, report compliance or non-compliance per category, citing concrete evidence (function names, line numbers, code snippets). Where gaps exist, implement fixes immediately using the sensible defaults described in this prompt.
+Review every Python file against the logging standards below. Report compliance with evidence and fix gaps using the defaults in this prompt and the baseline.
 
 ## Steps 👣
 
@@ -25,6 +25,12 @@ Audit every Python file in this repository against the logging standards defined
 
 For every file that uses logging (or should but does not), evaluate compliance against the categories below. Report each finding and remediate inline where feasible.
 
+### Step 3: Assess observability baseline compliance
+
+Use it for context and evaluate each runtime that emits structured logs against the Observability Baseline:
+
+- [.github/instructions/includes/observability-baseline.include.md](../instructions/includes/observability-baseline.include.md)
+
 ## Implementation requirements 🛠️
 
 ### Anti-patterns (flag and fix immediately) 🚫

.github/prompts/dev.implement-logging.prompt.md

@@ -14,7 +14,7 @@ Mandatory reads (must be loaded before using this skill):
 - [Python instructions](../../instructions/python.instructions.md) — use its identifiers when describing compliance.
 - [Local-first dev baseline](../../instructions/includes/local-first-dev-baseline.include.md)
 - [Quality gates baseline](../../instructions/includes/quality-gates-baseline.include.md)
-- [Observability logging baseline](../../instructions/includes/observability-logging-baseline.include.md)
+- [Observability logging baseline](../../instructions/includes/observability-baseline.include.md)
 - [AI-assisted change baseline](../../instructions/includes/ai-assisted-change-baseline.include.md)
 
 ## Inputs to confirm ✅

.github/skills/django-project/SKILL.md

@@ -14,7 +14,7 @@ Mandatory reads (must be loaded before using this skill):
 - [Python instructions](../../instructions/python.instructions.md) — use its identifiers when describing compliance.
 - [Local-first dev baseline](../../instructions/includes/local-first-dev-baseline.include.md)
 - [Quality gates baseline](../../instructions/includes/quality-gates-baseline.include.md)
-- [Observability logging baseline](../../instructions/includes/observability-logging-baseline.include.md)
+- [Observability logging baseline](../../instructions/includes/observability-baseline.include.md)
 - [AI-assisted change baseline](../../instructions/includes/ai-assisted-change-baseline.include.md)
 
 ## Inputs to confirm ✅