fix: TestContainerSupport agent job detection matches manifest comments

[Copilot]

TestContainerSupport subtests fail because strings.Contains(line, "agent:") matches the # gh-aw-manifest: JSON comment (which contains "agent:") before reaching the actual YAML job key. The test then exits the search prematurely on issues: thinking it's a new job.

• Changed agent job detection from substring match to exact line match:

// Before: matches "agent:" anywhere in any line (including manifest JSON)
if strings.Contains(line, string(constants.AgentJobName)+":") {

// After: matches only the YAML job definition line
agentJobLine := "  " + string(constants.AgentJobName) + ":"
if line == agentJobLine {

• Applied same fix to both TestContainerSupport and TestServicesSupport search loops

[Copilot]

Pull request overview

Fixes flaky agent-job detection in integration tests by ensuring the scan for the agent job matches the YAML job definition line exactly (avoiding accidental matches inside the # gh-aw-manifest: JSON header comment).

Changes:

• Replace strings.Contains(..., "agent:") with an exact match against the expected job key line (" agent:") in TestContainerSupport.
• Apply the same exact-line job detection in TestServicesSupport.

Show a summary per file

File	Description
pkg/workflow/container_services_test.go	Tightens agent job start detection to avoid false-positives from gh-aw-manifest header comments when validating container/services sections.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 1/1 changed files
• Comments generated: 1

[Copilot]

The agent-job detection change is applied here, but the same substring-based job detection pattern still exists in pkg/workflow/environment_test.go (see around environment_test.go:140-146). Because the generated header can include container image refs like "/agent:" inside the single-line "# gh-aw-manifest: ..." comment, that test loop is still vulnerable to the same false-positive and may keep failing CI. Consider applying the same exact-line match (or a shared helper) across all tests that scan for the agent job start.

[github-actions]

🧪 Test Quality Sentinel Report

Test Quality Score: 100/100

✅ Excellent test quality

Metric	Value
New/modified tests analyzed	2
✅ Design tests (behavioral contracts)	2 (100%)
⚠️ Implementation tests (low value)	0 (0%)
Tests with error/edge cases	2 (100%)
Duplicate test clusters	0
Test inflation detected	No
🚨 Coding-guideline violations	None

---

Test Classification Details

Test	File	Classification	Issues Detected
TestContainerSupport	pkg/workflow/container_services_test.go	✅ Design	None — behavioral contract verified
TestServicesSupport	pkg/workflow/container_services_test.go	✅ Design	None — behavioral contract verified

---

Summary of Changes

This PR fixes the agent-job detection logic inside both test functions. Previously, the loop used strings.Contains(line, agentJobName+":") which could falsely match YAML comments or other lines that contained the agent job name string. The fix extracts a precise line pattern (agentJobLine := " " + string(constants.AgentJobName) + ":") and uses strict equality (line == agentJobLine) to locate the job boundary.

Both TestContainerSupport and TestServicesSupport are table-driven integration tests that:

1. Write a real workflow markdown file to a temp directory
2. Invoke compiler.ParseWorkflowFile() and compiler.generateYAML() — real production code, no mocks
3. Assert on the observable output (the generated YAML) — that container: / services: sections appear correctly indented inside the agent job
4. Include an explicit "no container/no services" edge-case row that asserts the section is absent from the YAML

These are clean behavioral-contract tests. The fix makes the test more correct without weakening the contract being verified.

---

Language Support

Tests analyzed:

• 🐹 Go (*_test.go): 2 tests (integration — //go:build integration) ✅ build tag present

---

Verdict

✅ Check passed. 0% of new/modified tests are implementation tests (threshold: 30%). Both tests verify observable compiler output, cover the happy path and the absence-of-feature edge case, and use real component interactions with no mock libraries.

---

📖 Understanding Test Classifications

Design Tests (High Value) verify what the system does:

• Assert on observable outputs, return values, or state changes
• Cover error paths and boundary conditions
• Would catch a behavioral regression if deleted
• Remain valid even after internal refactoring

Implementation Tests (Low Value) verify how the system does it:

• Assert on internal function calls (mocking internals)
• Only test the happy path with typical inputs
• Break during legitimate refactoring even when behavior is correct
• Give false assurance: they pass even when the system is wrong

Goal: Shift toward tests that describe the system's behavioral contract — the promises it makes to its users and collaborators.

🧪 Test quality analysis by Test Quality Sentinel · ● 645.3K · ◷

[github-actions]

✅ Test Quality Sentinel: 100/100. Test quality is excellent — 0% of new/modified tests are implementation tests (threshold: 30%). Both modified tests are behavioral-contract integration tests that exercise real compiler code, cover the happy path and an edge case (absent feature), and now use precise job-line detection to eliminate false-positive matches on manifest comments.