test: trigger pr-triage workflow

[bhapas]

Dummy PR to test the pr-triage GitHub Actions workflow.

[github-actions]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[github-actions]

ECS PR Triage (automated)

PR Triage Report

PR: #1 — test: trigger pr-triage workflow
Classification: Direct PR
Change type: Documentation
Scope: Minor

Summary

This is a test PR that adds a single trailing newline to README.md. It is a trivial, no-op change with zero impact on schemas, tooling, or documentation content. The PR was explicitly created to test the pr-triage GitHub Actions workflow. It falls squarely into the Direct PR path per classification-rules §2 (bugfix/clarity — trivial whitespace change to a non-generated doc).

Files changed

• Schemas: none
• Generated: none
• Tooling/scripts/tests: none
• Docs (hand-authored): README.md (trailing newline added — 1 addition, 0 deletions)
• CI / GitHub: none
• RFCs: none

Routing decision

Direct PR is appropriate. The change touches only README.md (a hand-authored root documentation file) with a single trailing newline addition. No schema files, generated artifacts, tooling, or RFC content is affected. This matches classification-rules §2 ("Non-generated docs") with no triggers from §1 (RFC) or §3 (Needs Discussion). No RFC or maintainer discussion is required.

Risk notes

• Breaking / deprecation: No. Zero functional change.
• OTel / semconv: N/A. No schema or field changes.
• Scope / reuse: N/A. No fieldset, reuse, or categorization changes.

Completeness checklist

• PR description (all sections): Missing. The PR body is a single sentence ("Dummy PR to test the pr-triage GitHub Actions workflow.") and does not fill in any of the 7 template sections from .github/PULL_REQUEST_TEMPLATE.md. However, given that this is an intentional test PR with a trivial whitespace-only change, the missing template sections are understandable.
• CHANGELOG.next.md: Not required. No schemas/ or scripts/ files were changed. A changelog entry is not expected for this PR.
• make + committed generated outputs: Not required. No schema changes were made; no regeneration needed.
• OTel otel: on new/changed semconv-related fields: N/A. No field changes.
• Tests / make check: N/A. No functional changes to validate. The whitespace-only diff would not affect make check.
• CLA (contributor): Author is bhapas (Bharat Pasupula), the repository owner. CLA is assumed to be in order.

Recommended next actions

1. No action required for merge from a triage perspective. This is a trivial test PR with no schema, tooling, or documentation impact.
2. If this PR is purely for CI workflow testing and not intended to be merged long-term, consider closing it after the workflow test is validated.
3. If the PR were intended as a real contribution, the PR description should be updated to fill in the 7 template sections per .github/PULL_REQUEST_TEMPLATE.md.

---

Posted by PR Triage workflow

[github-actions]

ECS PR Triage (automated)

PR Triage Report

PR: #1 — test: trigger pr-triage workflow
Classification: Needs RFC
Change type: Mixed
Scope: Substantial

Summary

This PR introduces a new top-level llm_tool field set (schemas/llm_tool.yml) with 20 new leaf fields covering LLM tool/function call identity, parameters, execution results, safety classification, chain tracking, and human approval workflows. The PR also includes an RFC document (rfcs/text/0054-llm-tool-fields.md) and a supporting YAML snippet (rfcs/text/0054/llm_tool.yml). Because it adds a new top-level field set and introduces 20 new leaf fields (well above the ~5-field heuristic), this change requires the full RFC process. The RFC document is present in the PR, which aligns with the ECS convention that proposal and implementation land together.

Files changed

• Schemas: schemas/llm_tool.yml (added — new top-level field set, 217 lines, 20 leaf fields)
• Generated: none — missing, expected when schemas/ changes (evidence that make was not run)
• Tooling/scripts/tests: none
• Docs (hand-authored): none — generated docs/reference/ artifacts also missing
• CI / GitHub: none
• RFCs: rfcs/text/0054-llm-tool-fields.md (added), rfcs/text/0054/llm_tool.yml (added)
• Other: README.md (trivial whitespace addition — trailing newline)

Routing decision

Needs RFC — multiple triggers from classification-rules §1:

1. New top-level field set: New file schemas/llm_tool.yml introduces a previously non-existent llm_tool field set. Per §1: "New schemas/<name>.yml (new name: at field-set level)" → RFC required.
2. Large batch of new fields: The PR adds 20 new leaf fields (llm_tool.id, llm_tool.name, llm_tool.type, llm_tool.description, llm_tool.parameters, llm_tool.result.content, llm_tool.result.status, llm_tool.result.error.message, llm_tool.result.error.type, llm_tool.result.duration_ms, llm_tool.result.tokens_used, llm_tool.safety.classification, llm_tool.safety.policy_id, llm_tool.safety.reason, llm_tool.chain.id, llm_tool.chain.step, llm_tool.chain.max_steps, llm_tool.approval.required, llm_tool.approval.status, llm_tool.approval.reviewer). This exceeds the ~5-field heuristic by a wide margin → RFC required per §1.
3. Novel use case: LLM tool/function call observability is a domain not currently covered by existing ECS field sets. The existing gen_ai.* fields cover model-level metadata, not individual tool invocations → RFC required per §1.

The PR does include an RFC document (rfcs/text/0054-llm-tool-fields.md) at Proposal stage with alpha target maturity, which is the correct approach. The RFC and schema implementation are bundled together per current ECS process.

Risk notes

• Breaking / deprecation: No — all fields are new additions at alpha maturity with level: extended. No existing fields are modified or removed.
• OTel / semconv: The RFC acknowledges OTel GenAI semconv is actively developing tool-call attributes (gen_ai.tool.call.id, gen_ai.tool.name). No otel: metadata is present on schema fields yet. The RFC states alignment will be added once OTel spec stabilizes. This is acceptable at alpha maturity but should be revisited before beta promotion.
• Scope / reuse: New top-level field set llm_tool. No reusable entries defined (field set is not nested under other field sets). Uses flattened type for llm_tool.parameters — justified in the RFC due to heterogeneous, unbounded tool parameter schemas. Multiple allowed_values lists defined on llm_tool.type, llm_tool.result.status, llm_tool.safety.classification, and llm_tool.approval.status — these are new categorization values specific to this field set, not modifications to core ECS categorization fields.

Completeness checklist

• PR description (all sections) — MISSING. The PR body is only "Dummy PR to test the pr-triage GitHub Actions workflow." None of the 7 template sections from .github/PULL_REQUEST_TEMPLATE.md are filled (what does this PR do, fields affected, why necessary, documentation, built ECS, tests, reviewer notes).
• CHANGELOG.next.md — MISSING. Schema changes in schemas/ require a CHANGELOG.next.md entry under "Schema Changes > Added" with #NNNN link.
• make + committed generated outputs — MISSING. schemas/llm_tool.yml was added but no generated/ or docs/reference/ artifacts are in the diff. The contributor must run make and commit the generated outputs.
• OTel otel: on new/changed semconv-related fields — MISSING (but not blocking). The fields relate to OTel GenAI semconv tool-call attributes. Adding otel: metadata is encouraged but not required, especially at alpha maturity.
• Tests / make check — UNKNOWN. No evidence in the PR that make test or make check was run. The PR description does not confirm this.
• CLA (contributor) — UNKNOWN. Cannot verify from PR metadata alone.

Recommended next actions

1. Contributor: Fill in all 7 sections of the PR description template (.github/PULL_REQUEST_TEMPLATE.md). The current body is a placeholder and does not describe the change.
2. Contributor: Run make to regenerate all artifacts and commit the generated/ and docs/reference/ output files.
3. Contributor: Run make test and make check to verify the schema is valid and passes CI checks.
4. Contributor: Add a CHANGELOG.next.md entry under "Schema Changes > Added" referencing the PR number (e.g., - Added llm_tool field set for LLM tool call observability. #1).
5. Contributor: Consider adding otel: metadata to fields that have clear OTel semconv counterparts (e.g., llm_tool.id ↔ gen_ai.tool.call.id, llm_tool.name ↔ gen_ai.tool.name), though this is optional at alpha.
6. Maintainers: Review the RFC at rfcs/text/0054-llm-tool-fields.md for completeness and alignment with ECS design principles. Key discussion points: relationship to gen_ai.*, flattened type justification for parameters, and the scope of allowed_values on llm_tool.type.
7. Reference: The RFC process is documented at rfcs/PROCESS.md and the template is at rfcs/0000-rfc-template.md. The ecs-rfc-guide skill provides a detailed walkthrough of the Proposal process.

---

Posted by PR Triage workflow

[github-actions]

ECS PR Triage (automated)

PR Triage Report

PR: #1 — test: trigger pr-triage workflow
Classification: Needs RFC
Change type: Mixed
Scope: Substantial

Summary

This PR introduces a new top-level llm_tool.* field set (~20 new leaf fields) to capture LLM tool/function calls in agentic workflows. The PR includes an RFC (0054) and the schema implementation landing together, which is the correct approach per ECS process. However, the PR description is a placeholder ("Dummy PR to test the pr-triage GitHub Actions workflow"), generated artifacts are missing, and no changelog entry is present. Multiple RFC triggers are matched: new field set file, large batch of fields, and a novel use case (LLM tool observability).

Files changed

• Schemas: schemas/llm_tool.yml (ADDED — new top-level field set, 218 lines, ~20 leaf fields)
• Generated: none — missing: generated/ and docs/reference/ artifacts are absent despite a new schema file being added (evidence that make was not run or outputs were not committed)
• Tooling/scripts/tests: none
• Docs (hand-authored): none
• CI / GitHub: none
• RFCs: rfcs/text/0054-llm-tool-fields.md (ADDED), rfcs/text/0054/llm_tool.yml (ADDED)
• Other: README.md (trivial trailing newline addition)

Routing decision

Classification: Needs RFC — the contributor has correctly included an RFC. Three triggers from classification-rules §1 apply:

1. New top-level field set: New file schemas/llm_tool.yml introduces name: llm_tool at the field-set level. This is a clear RFC trigger per §1 ("New schemas/<name>.yml — new name: at field-set level").
2. Large batch: ~20 new leaf fields in a single PR, well above the ~5 heuristic threshold in §1.
3. Novel / unaddressed use case: LLM tool call observability for agentic workflows is a domain not currently covered by existing ECS field sets. The gen_ai.* field set covers model-level metadata, but tool invocation tracking is a new concept.

The contributor has followed the correct path by including RFC 0054 alongside the schema implementation. The RFC is well-structured with summary, usage examples, field definitions, source data (3 real-world JSON examples), scope of impact, and concerns with resolutions. The RFC number 0054 is the next available after the existing highest (0053).

Risk notes

• Breaking / deprecation: No. All fields are new additions at alpha maturity and extended level. No existing fields are modified or removed.
• OTel / semconv: The RFC acknowledges OTel GenAI semconv overlap (tool call attributes under active development in OTel). No otel: metadata blocks are present in schemas/llm_tool.yml. The RFC states alignment will be added once OTel spec stabilizes. Given alpha maturity, this is acceptable but otel: blocks are encouraged where clear mappings exist (e.g., llm_tool.id maps to gen_ai.tool.call.id, llm_tool.name maps to gen_ai.tool.name).
• Scope / reuse: New field set with no reusable entries. Uses flattened type on llm_tool.parameters — justified in the RFC due to heterogeneous, unbounded tool parameter schemas. No object types without children. The 1:N relationship with gen_ai.* events is clearly documented.

Completeness checklist

• PR description (all sections) — MISSING. The PR body is "Dummy PR to test the pr-triage GitHub Actions workflow." None of the 7 required template sections are filled (What does this PR do?, Which ECS fields are affected?, Why is this change necessary?, Documentation?, Built ECS?, Validation tests?, Anything else?). The contributor must fill out the full PR template from .github/PULL_REQUEST_TEMPLATE.md.
• CHANGELOG.next.md — MISSING. schemas/ files changed, so a changelog entry is required. Add an entry under "Schema Changes > Added" with the PR number (e.g., #1) describing the new llm_tool.* field set.
• make + committed generated outputs — MISSING. A new schema file schemas/llm_tool.yml was added but no generated/ or docs/reference/ artifacts appear in the diff. The contributor must run make and commit all regenerated outputs.
• OTel otel: on new/changed semconv-related fields — MISSING (encouraged). Several fields have clear OTel semconv counterparts (e.g., llm_tool.id to gen_ai.tool.call.id, llm_tool.name to gen_ai.tool.name). Adding otel: metadata is encouraged but not a merge gate, especially at alpha maturity.
• Tests / make check — UNKNOWN. No evidence that make test or make check was run. The contributor should run both and confirm they pass.
• CLA (contributor) — UNKNOWN. Cannot verify from the diff; GitHub CLA bot should confirm.

Recommended next actions

1. Fill out the PR description using all 7 sections from the PR template (.github/PULL_REQUEST_TEMPLATE.md). The RFC content provides excellent material to draw from.
2. Run make to regenerate all artifacts (generated/, docs/reference/) and commit the outputs.
3. Run make test and make check to validate the schema passes CI-equivalent checks (strict mode, yamllint, etc.).
4. Add a CHANGELOG.next.md entry under "Schema Changes > Added" with the PR number and a description of the new llm_tool.* field set.
5. Consider adding otel: metadata to fields with clear OTel semconv counterparts (at minimum llm_tool.id, llm_tool.name, llm_tool.type). This is optional but encouraged for alignment tracking.
6. Maintainer review should evaluate the RFC holistically: field naming conventions, overlap/complementarity with gen_ai.*, the flattened type justification for parameters, and whether the ~20-field scope is appropriate for an initial alpha introduction.
7. Reference: The RFC process is documented at rfcs/PROCESS.md and the template at rfcs/0000-rfc-template.md. See the ecs-rfc-guide skill for a detailed walkthrough of RFC requirements.

---

Posted by PR Triage workflow