Make startup reminder align with configured section names

This change allows arbitrary postCompactionSections, but the injected post-compaction message still hardcodes “Execute your Session Startup sequence now.” If a deployment configures only non-Session Startup sections (for example ['Boot Sequence'] or just safety sections), the runtime now sends contradictory guidance: it extracts custom sections yet still instructs the agent to run a section name that may not exist. In those configs this can reintroduce the same false “missing startup section/file” behavior the change is trying to eliminate.

Useful? React with 👍 / 👎.

Fixed in 9b470853f (same session, pushed before this review fired).

The prose now branches explicitly on whether the active section set matches the default ["Session Startup", "Red Lines"] pair:

const prose = isDefaultSections
  ? "...Execute your Session Startup sequence now..."
  : `Re-read the sections injected below (${sectionNames.join(", ")}) and follow your configured startup procedure...`;

Deployments using custom sections (e.g. ["Boot Sequence"]) receive prose that names their actual sections — no reference to "Session Startup" is injected. Default deployments are fully backward compatible.

Two regression tests verify both branches:

• does NOT reference "Session Startup" in prose when custom sections are configured
• uses default "Session Startup" prose when default sections are active

22/22 tests passing.

Fixed in 9b47085 — the injected prose now adapts to the configured section names instead of hardcoding 'Session Startup'. When custom sections are configured, the message references those section names directly.

Describe only sections that were actually injected

In readPostCompactionContext, custom-mode prose is built from sectionNames.join(", ") (the configured list), not from the sections that extractSections actually found. If config requests multiple headings and only some exist in AGENTS.md, the function still returns context but claims all configured sections were injected, which can send the agent looking for non-existent headings and recreate misleading “missing section” behavior in partially migrated setups.

Useful? React with 👍 / 👎.

Fixed in 678cd65 — prose now references only section names that were actually found in the extracted content (matched by heading regex), so partially migrated setups won't reference non-existent headings. 22/22 tests passing.

Derive injected section names from extraction results

The new foundSectionNames detection can report sections that were not actually injected because it regex-scans sections.join("\n\n") for heading text instead of using extraction metadata. In particular, extractSections intentionally ignores headings inside fenced code blocks, but those lines are still present in extracted section content, so a code block containing ## <configured-name> will make displayNames include that missing section. This reintroduces misleading post-compaction prose in repos whose AGENTS sections include markdown examples.

Useful? React with 👍 / 👎.

Fixed in 2c31a12 — replaced regex-based heading detection with an extractSections output parameter (foundNames). Now extractSections pushes the section name only when it actually matches a heading outside code blocks, so code block examples containing ## SectionName won't false-match.

Preserve legacy section fallback when defaults are absent

With postCompactionSections unset, this path now extracts only Session Startup/Red Lines and immediately returns null when those headings are missing, which drops the previous fallback to legacy Every Session/Safety sections. Any workspace still using older AGENTS templates will therefore lose post-compaction context injection after this commit, even though other compaction code paths still treat those legacy names as supported; please keep a fallback (or alias mapping) so existing deployments don’t silently regress.

Useful? React with 👍 / 👎.

Fixed in 444d6c4 — when using defaults (no explicit postCompactionSections), the code now falls back to legacy section names (Every Session / Safety) if the current headings aren't found. Explicitly configured sections skip the fallback. 22/22 tests passing.

Apply legacy fallback for explicit default section config

When agents.defaults.compaction.postCompactionSections is explicitly set to ['Session Startup', 'Red Lines'], this condition skips the legacy fallback path and returns null on older AGENTS.md files that only have Every Session/Safety. In contrast, leaving the field unset still falls back successfully, so explicitly pinning the documented defaults changes behavior and can silently disable post-compaction context injection in partially migrated deployments.

Useful? React with 👍 / 👎.

Fixed in 5e8f31d — the legacy fallback condition now also triggers when postCompactionSections is explicitly set to the default pair (["Session Startup", "Red Lines"]). Explicitly pinning the documented defaults now behaves identically to leaving the field unset. Added a dedicated test case for this scenario. 23/23 tests passing.

Treat default section pair as order-insensitive

isExplicitDefaults uses index-by-index comparison, so postCompactionSections: ["Red Lines", "Session Startup"] is treated as a custom config instead of the default pair. In that case legacy fallback (Every Session/Safety) is skipped, and older AGENTS.md templates return null, silently disabling post-compaction context injection even though the same two default section names were configured.

Useful? React with 👍 / 👎.

Compare explicit default sections without order dependence

The explicit-default check uses index-by-index comparison, so postCompactionSections: ["Red Lines", "Session Startup"] is treated as a custom set instead of the documented defaults. In workspaces that still use legacy AGENTS.md headings (Every Session/Safety), this causes the legacy fallback path to be skipped and readPostCompactionContext returns null, silently disabling post-compaction reinjection just because the two default names were listed in a different order.

Useful? React with 👍 / 👎.