OCSF shorthand renders Unknown and Other severities as [INFO]

從 crates/openshell-ocsf/src/format/shorthand.rs 中的 severity_tag 開始，將其與 severity_char 以及其中的測試進行比較。閱讀 crates/openshell-ocsf/src/enums/severity.rs，然後執行 cargo test -p openshell-ocsf。完成標準是涵蓋 0..=6 和 99 的完整映射，其中 Unknown 和 Other 要與 Informational 區分開，並與同級輔助函式保持一致。

OCSF shorthand renders Unknown and Other severities as [INFO]

User Story

As someone reading sandbox OCSF audit logs in openshell.log or a gRPC log push, I want the severity tag on each line to reflect the event's actual severity, so that an event of unclassified severity is distinguishable from one deliberately marked informational.

Problem Statement

severity_tag in crates/openshell-ocsf/src/format/shorthand.rs maps only 2..=6 explicitly and sends every other value to a _ => "[INFO]" arm:

pub fn severity_tag(severity_id: u8) -> &'static str {
    match severity_id {
        2 => "[LOW]",
        3 => "[MED]",
        4 => "[HIGH]",
        5 => "[CRIT]",
        6 => "[FATAL]",
        _ => "[INFO]",
    }
}

SeverityId has two members outside 2..=6 that are real, serializable values: Unknown = 0 and Other = 99 (crates/openshell-ocsf/src/enums/severity.rs). Both land in the _ arm, so they render as [INFO] — the same tag as SeverityId::Informational = 1, which is the default severity for most builders (api_activity, base, config, http, lifecycle, network, process, ssh all default to SeverityId::Informational).

The two sibling helpers in the same module already disagree with this. severity_char (line 27) maps both 0 and 99 to ' ', and its test test_severity_char_mapping asserts exactly that. SeverityId::shorthand_char in the enum also returns ' ' for both. severity_tag is the one that is actually used for rendering (format_shorthand, line 202), and it is the one that is wrong.

Impact / Why This Matters

[INFO] is the most common tag in the log, so folding two distinct severities into it makes an unclassified event indistinguishable from an informational one. For an audit trail this means a line that reads as routine cannot be triaged by severity alone; an operator filtering for non-informational events would not surface it. The full OCSF JSON is still correct — severity_id serializes as 0 or 99 — so this is a display-projection bug, not a data bug, but openshell.log is what most operators read.

There is no workaround today. The only way to recover the real severity is to read the JSONL file rather than the shorthand log.

Acceptance Criteria

• severity_tag(0) and severity_tag(99) do not return "[INFO]".
• severity_tag(0) and severity_tag(99) are identical to each other and distinct from severity_tag(1).
• severity_tag is consistent with severity_char and SeverityId::shorthand_char for the same input.
• A unit test covers the full 0..=6 plus 99 mapping, not just the 0..=6 range that was already handled.
• severity_tag(1) through severity_tag(6) are unchanged, so existing log consumers are unaffected.

Reproduction Steps

1. Build any event whose severity_id is 0 or 99 through the OCSF builders, or call severity_tag directly.
2. Format it with OcsfEvent::format_shorthand.
3. Observe the severity tag in the output.

severity_tag(0)  == "[INFO]"   // expected: distinct from Informational
severity_tag(99) == "[INFO]"   // expected: distinct from Informational
severity_tag(1)  == "[INFO]"   // Informational
severity_char(0) == ' '        // Unknown — the two helpers disagree
severity_char(99) == ' '       // Other  — the two helpers disagree

Environment

• OpenShell: main at commit cf1bbb965
• OS: Windows 11
• Toolchain: 1.98.0-x86_64-pc-windows-gnu (the pinned 1.95.0 MSVC toolchain needs link.exe, which is not installed on this machine, so I built with the GNU toolchain for the same x86_64-pc-windows target)
• No mise run available in this environment, so verification was cargo test -p openshell-ocsf and cargo clippy -p openshell-ocsf --all-targets -- -D warnings rather than mise run pre-commit

Logs

Not applicable — this is a formatting defect, reproducible with a direct unit assertion as shown above.

Notes

I have a branch and a candidate fix ready at aniruddhaadak80:fix/ocsf-severity-tag-unknown (one-line change plus a test), but I am not opening a PR yet because the vouch-check workflow will auto-close it. I would rather ask first.

I picked [UNKN] to match the existing 5-character tags ([INFO], [LOW], [MED], [HIGH]), which keeps the log column alignment. A maintainer may prefer a different spelling, or may prefer severity_tag to derive from SeverityId::shorthand_char / label() so the three helpers cannot drift apart again — I think that is the more durable fix, but it is a larger diff and I did not want to make that call unilaterally.