Derive implement issue titles from command text

[sepo-agent-app]

Summary

• Derive explicit /implement tracking issue titles from the command detail.
• Keep Implement requested change as the fallback when no detail is provided.
• Document the behavior and add triage regression coverage.

Tests

• npm --prefix .agent run build && node --test .agent/dist/__tests__/triage.test.js

Closes #228

[lolipopshock]

@sepo-agent /answer

When an explicit `/implement` request on a pull request or discussion creates a tracking issue, the issue title is derived from the text after `/implement

This is not what i meant. The agent should generate a proper title for the issue given the description and the context.

[sepo-agent-app]

You’re right. PR #232 implements the wrong behavior.

Current architecture explains why: explicit routes skip dispatch triage in agent-router.yml, then resolve-dispatch.ts uses deterministic metadata from buildRequestedRouteDecision. The tracking issue is then created from that issue_title in agent-router.yml.

The fix should not copy text after /implement. It should add a lightweight title/body generation step for explicit /implement on PRs/discussions, using the original mention plus target context, while still treating the slash command as explicit approval to run agent-implement.

Concrete revision plan:

1. Revert the command-tail title extraction in PR Derive implement issue titles from command text #232.
2. Add or reuse an agent prompt that generates only tracking issue metadata: concise title under 70 chars and structured issue body.
3. Run that metadata generation when requested_route == implement and the target is not already an issue.
4. Keep needsApproval: false for explicit /implement.
5. Keep Implement requested change only as an error/fallback path.
6. Add tests proving /implement please fix this does not literally become the title, and that PR/discussion context drives the generated metadata.

So the intended behavior is: /implement selects the route; the agent still synthesizes the issue title from the request and surrounding context.

[lolipopshock]

You’re right. PR #232 implements the wrong behavior.

Current architecture explains why: explicit routes skip dispatch triage in agent-router.yml, then resolve-dispatch.ts uses deterministic metadata from buildRequestedRouteDecision. The tracking issue is then created from that issue_title in agent-router.yml.

The fix should not copy text after /implement. It should add a lightweight title/body generation step for explicit /implement on PRs/discussions, using the original mention plus target context, while still treating the slash command as explicit approval to run agent-implement.

Concrete revision plan:

1. Revert the command-tail title extraction in PR Derive implement issue titles from command text #232.
2. Add or reuse an agent prompt that generates only tracking issue metadata: concise title under 70 chars and structured issue body.
3. Run that metadata generation when requested_route == implement and the target is not already an issue.
4. Keep needsApproval: false for explicit /implement.
5. Keep Implement requested change only as an error/fallback path.
6. Add tests proving /implement please fix this does not literally become the title, and that PR/discussion context drives the generated metadata.

So the intended behavior is: /implement selects the route; the agent still synthesizes the issue title from the request and surrounding context.

@sepo-agent /implement

[sepo-agent-app]

Implementing this request — tracking in #234.

[lolipopshock]

@sepo-agent /answer

can you compare it with #236

[sepo-agent-app]

Yes. Compared against #236, current #232 is the stronger version.

Both PRs now aim at the right product behavior: explicit /implement still selects the route, while a metadata-only agent pass generates the tracking issue title/body from PR or discussion context.

Key differences:

Area	#232	#236	Better
Access policy before metadata generation	Resolves explicit route authorization first, then runs metadata only if route is authorized implement	Runs metadata generation based on raw requested_route == implement before dispatch policy resolution	#232
Metadata agent permissions	Uses permission_mode: approve-reads	Uses permission_mode: approve-all	#232
Metadata schema	Prompt returns only issue_title and issue_body; parser validates those fields	Prompt returns a full dispatch-shaped object including route, needs_approval, summary, confidence	#232, narrower contract
Route safety	Generated metadata cannot change the route by shape	Generated response is normalized as dispatch output, then route mismatch is ignored	#236 has a guard, but #232 avoids the risk earlier
Fallback behavior	Invalid/missing generated metadata falls back to generic implement metadata	Invalid/mismatched generated metadata falls back too	Tie
Docs/tests coverage	Broader: request lifecycle docs, supported workflows docs, triage tests, resolve-dispatch tests, workflow contract test	Good but narrower; lacks request-lifecycle update and uses approve-all in workflow test	#232

The biggest concern in #236 is this line in its workflow diff: the metadata generation step uses permission_mode: approve-all. Since that prompt only needs to read context and emit JSON, #232’s approve-reads is the safer design.

I would merge or continue with #232, not #236. #236 is conceptually aligned, but it looks like an earlier/parallel implementation that missed the later hardening done on #232.

[lolipopshock]

@sepo-agent /answer

Right now we have some additional prompts for the implement request endpoint. Just want to double check that they are expected right? B/c previous for other implement route they do not have the agent generated titles and metadata?

[sepo-agent-app]

Yes, the additional prompt is expected for this specific path.

The distinction is:

Implement path	Does it already have agent-generated issue metadata?	Extra metadata prompt needed?
Free-form request triaged to implement	Yes. The normal dispatch prompt generates issue_title / issue_body.	No
Explicit /implement on an issue	No tracking issue is created; implementation runs against the issue.	No
Explicit /implement on a PR/discussion	Previously no, because explicit routes bypass dispatch triage. A tracking issue must be created first.	Yes
agent/implement label on PR/discussion	Same explicit route path.	Yes

So the new agent-implement-metadata.md prompt is there to fill the gap only for explicit non-issue implement requests. It is not route selection and should not approve anything; /implement already did that. It only returns issue_title and issue_body.

That is why #232 also gates the prompt behind explicit route authorization, non-issue target, and read-only permissions in agent-router.yml. Then resolve-dispatch.ts uses the generated metadata if valid, otherwise falls back to Implement requested change.

So yes: the extra prompt is intentional because explicit /implement skips the normal dispatch prompt that other implement flows already use for generated titles/metadata.

[lolipopshock]

@sepo-agent /answer

But we also added a bunch of auth checker in this PR -> is that intended?

[sepo-agent-app]

Yes, the auth check is intentional, but I agree it looks heavier than the core product change.

Why it was added: the new metadata prompt runs before creating the tracking issue, and it can read PR/discussion context. So #232 first reuses the existing dispatch-policy path to confirm the explicit route is actually authorized before letting that metadata prompt run. That is the new Resolve explicit route authorization step in agent-router.yml, and the metadata prompt only runs after explicit_dispatch.outputs.route == 'implement'.

That part is expected. It prevents this sequence:

1. Someone sends explicit /implement.
2. The router starts a context-reading metadata agent prompt.
3. Only later do we discover the actor was not allowed to run implement.

The current PR avoids that by checking AGENT_ACCESS_POLICY first.

One nuance: the current check runs for all explicit routes, even though the new metadata prompt only needs it for explicit implement on non-issue targets. The final Resolve route step still applies policy again afterward, so this precheck is mainly a guard for the metadata prompt. If we want the PR to feel narrower, it would be reasonable to scope that precheck to:

requested_route == 'implement' && target_kind != 'issue'

So: do not remove the auth checker entirely, but it is fair to tighten its condition so it is clearly just protecting the new metadata-generation path, not changing the broader explicit-route auth model.

[lolipopshock]

@sepo-agent /answer

     - name: Resolve explicit route authorization
        if: >-
          steps.context.outputs.should_respond == 'true' &&
          steps.context.outputs.requested_route != ''
        id: explicit_dispatch
        env:
          REQUESTED_ROUTE: ${{ steps.context.outputs.requested_route }}
          REQUESTED_SKILL: ${{ steps.context.outputs.requested_skill }}
          REQUEST_TEXT: ${{ steps.context.outputs.body }}
          TARGET_KIND: ${{ steps.context.outputs.target_kind }}
          AUTHOR_ASSOCIATION: ${{ steps.context.outputs.association }}
          ACCESS_POLICY: ${{ inputs.access_policy }}
          REPOSITORY_PRIVATE: ${{ github.event.repository.private && 'true' || 'false' }}
        run: node .agent/dist/cli/resolve-dispatch.js

      - name: Require dispatch provider
        id: dispatch_provider
        if: >-
      - name: Resolve task timeout
        if: >-
          steps.context.outputs.should_respond == 'true' &&
          (
            steps.context.outputs.requested_route == '' ||
            (
              steps.explicit_dispatch.outputs.route == 'implement' &&
              steps.context.outputs.target_kind != 'issue' &&
              steps.provider.outputs.provider != ''
            )
          )

There are two questions here:

1. for the addition of the resolve-dispatch.js step: shouldn't existing code also check the auth and guard implement?
2. why do we dispatch_provider conditions? is it necessary? is it too much "gating" ?

[sepo-agent-app]

1. Existing code already checks auth before actual implement dispatch.
   The final Resolve route step already calls resolve-dispatch.js, which applies AGENT_ACCESS_POLICY before the route output is used by the implement job.

   The reason Derive implement issue titles from command text #232 adds an earlier Resolve explicit route authorization step is narrower: the new metadata prompt runs before the final Resolve route step, because its output becomes part of the final route metadata. So without the precheck, an unauthorized explicit /implement could still trigger a context-reading metadata agent pass before being denied later.

   So the auth precheck is intended, but it only needs to protect this new metadata-generation path. I’d be comfortable narrowing it to:

   requested_route == 'implement' && target_kind != 'issue'

   That would make it clearer this is not a broader auth-model change.

2. The provider gating is mostly necessary, but should stay best-effort.
   There are two provider concepts here:

   • dispatch_provider: required for normal route-selection triage when requested_route == ''.
   • provider: optional early provider resolution used by the new metadata prompt.

   For explicit /implement, we should not require a dispatch provider just to proceed. Metadata generation is best-effort: if no provider is available, skip the metadata prompt and fall back to Implement requested change.

   The condition:

   steps.explicit_dispatch.outputs.route == 'implement' &&
   steps.context.outputs.target_kind != 'issue' &&
   steps.provider.outputs.provider != ''

   is there so timeout resolution and the metadata prompt only run when the metadata prompt can actually run. That part is reasonable.

   My take: the intent is right, but the workflow would read cleaner if the new precheck and timeout/provider gating were scoped exactly to “explicit implement on non-issue target with provider available.” The important part is: do not make explicit implement depend on provider availability; provider absence should just mean fallback metadata.

[lolipopshock]

Existing code already checks auth before actual implement dispatch.
The final Resolve route step already calls resolve-dispatch.js, which applies AGENT_ACCESS_POLICY before the route output is used by the implement job.

The reason #232 adds an earlier Resolve explicit route authorization step is narrower: the new metadata prompt runs before the final Resolve route step, because its output becomes part of the final route metadata. So without the precheck, an unauthorized explicit /implement could still trigger a context-reading metadata agent pass before being denied later.

So the auth precheck is intended, but it only needs to protect this new metadata-generation path. I’d be comfortable narrowing it to:

requested_route == 'implement' && target_kind != 'issue'
That would make it clearer this is not a broader auth-model change.

@sepo-agent /answer so the questions is, after adding this new gate, should we remove the older gate?

[sepo-agent-app]

No. I would not remove the older/final gate.

The new gate is a precheck only. Its job is to prevent an unauthorized explicit /implement from running the new metadata prompt before policy has been checked.

The older/final Resolve route gate should stay as the source of truth because it still:

• applies AGENT_ACCESS_POLICY to the actual route output before any route job runs;
• handles all routes, not just explicit non-issue implement;
• applies policy after metadata is merged/fallbacked;
• emits the canonical route, needs_approval, issue_title, issue_body, and skill outputs used by downstream jobs.

So the right shape is:

1. Precheck gate: only for explicit /implement on non-issue targets, before metadata generation.
2. Final gate: always keep it; it decides what the workflow is actually allowed to do.

What I would change is not removing the older gate, but narrowing the new one so it does not look like a second general auth system:

steps.context.outputs.should_respond == 'true' &&
steps.context.outputs.requested_route == 'implement' &&
steps.context.outputs.target_kind != 'issue'

Then keep the final Resolve route step unchanged as the authoritative dispatch-policy gate.

[lolipopshock]

No. I would not remove the older/final gate.

The new gate is a precheck only. Its job is to prevent an unauthorized explicit /implement from running the new metadata prompt before policy has been checked.

The older/final Resolve route gate should stay as the source of truth because it still:

• applies AGENT_ACCESS_POLICY to the actual route output before any route job runs;
• handles all routes, not just explicit non-issue implement;
• applies policy after metadata is merged/fallbacked;
• emits the canonical route, needs_approval, issue_title, issue_body, and skill outputs used by downstream jobs.

So the right shape is:

1. Precheck gate: only for explicit /implement on non-issue targets, before metadata generation.
2. Final gate: always keep it; it decides what the workflow is actually allowed to do.

What I would change is not removing the older gate, but narrowing the new one so it does not look like a second general auth system:

steps.context.outputs.should_respond == 'true' &&
steps.context.outputs.requested_route == 'implement' &&
steps.context.outputs.target_kind != 'issue'

Then keep the final Resolve route step unchanged as the authoritative dispatch-policy gate.

@sepo-agent /answer now I really don't get it. Since we have a later gating, why don't we reuse the later gating for the same metadata generation? Or are you saying the later gating cannot be reused easily?

[sepo-agent-app]

You’re right to push on this. The later gate cannot be reused as a single workflow step because of an ordering dependency.

Current desired flow is:

extract context
→ decide whether explicit /implement is authorized enough to run metadata prompt
→ run metadata prompt
→ final resolve-dispatch using generated metadata
→ create issue / dispatch implement

The later Resolve route step needs the metadata prompt output:

RESPONSE_FILE: ${{ steps.triage.outputs.response_file || steps.implement_metadata.outputs.response_file }}

So if we tried to use only the later gate, we get a cycle:

Need final Resolve route to know whether metadata prompt is allowed.
Need metadata prompt output before final Resolve route can produce final issue_title/body.

That is why the PR adds an earlier precheck. It is not a separate auth model; it is an early call to the same policy machinery so the metadata prompt does not run before authorization.

Could we restructure to avoid this shape? Yes, but it would be more awkward:

1. Run resolve-dispatch.js early with fallback metadata.
2. Run metadata prompt if authorized.
3. Run another merge/finalize step to replace fallback title/body.

That still has two phases; it just moves the duplication around.

So the honest answer is: we can reuse the same code, but not the same later workflow step, because the later step depends on metadata that has not been generated yet. The current approach is reasonable if the precheck is narrowly scoped and clearly named as a metadata precheck.

[lolipopshock]

@sepo-agent /answer

Final gate: always keep it; it decides what the workflow is actually allowed to do.
What I would change is not removing the older gate, but narrowing the new one so it does not look like a second general auth system:

steps.context.outputs.should_respond == 'true' &&
steps.context.outputs.requested_route == 'implement' &&
steps.context.outputs.target_kind != 'issue'
Then keep the final Resolve route step unchanged as the authoritative dispatch-policy gate.

Why there's a != issue in the condition?

[sepo-agent-app]

Because the metadata prompt is only needed when Sepo must create a new tracking issue.

For explicit /implement on an existing issue:

issue comment → /implement → run agent-implement on that same issue

There is no new issue to title, so generated issue_title / issue_body are irrelevant.

For explicit /implement on a PR or discussion:

PR/discussion comment → /implement → create tracking issue → run agent-implement on that issue

That is the case where we need generated metadata for the tracking issue.

So target_kind != 'issue' mirrors the later issue-creation condition: only non-issue surfaces need a tracking issue.

That said, for readability I’d slightly prefer the condition be more explicit if only PRs/discussions are intended:

steps.context.outputs.requested_route == 'implement' &&
(
  steps.context.outputs.target_kind == 'pull_request' ||
  steps.context.outputs.target_kind == 'discussion'
)

Functionally, != 'issue' matches the current create-issue path; explicit PR/discussion checks communicate the intent better.

[lolipopshock]

@sepo-agent /answer

What I would change is not removing the older gate, but narrowing the new one so it does not look like a second general auth system:

steps.context.outputs.should_respond == 'true' &&
steps.context.outputs.requested_route == 'implement' &&
steps.context.outputs.target_kind != 'issue'
Then keep the final Resolve route step unchanged as the authoritative dispatch-policy gate.

Good that's the intended change right?

[sepo-agent-app]

Yes. That is the intended change.

Keep the final Resolve route step unchanged as the authoritative dispatch-policy gate, and narrow the new precheck so it only exists to protect the metadata prompt path:

steps.context.outputs.should_respond == 'true' &&
steps.context.outputs.requested_route == 'implement' &&
steps.context.outputs.target_kind != 'issue'

That way the PR reads as:

• normal explicit-route authorization remains where it already was;
• the new early check is only a precheck for generated tracking-issue metadata;
• existing issue /implement and other explicit routes are not pulled into an extra auth-looking path.

[lolipopshock]

Yes. That is the intended change.

Keep the final Resolve route step unchanged as the authoritative dispatch-policy gate, and narrow the new precheck so it only exists to protect the metadata prompt path:

steps.context.outputs.should_respond == 'true' &&
steps.context.outputs.requested_route == 'implement' &&
steps.context.outputs.target_kind != 'issue'

That way the PR reads as:

• normal explicit-route authorization remains where it already was;
• the new early check is only a precheck for generated tracking-issue metadata;
• existing issue /implement and other explicit routes are not pulled into an extra auth-looking path.

@sepo-agent /orchestrate can you implement the minimum fix and then review it?

[sepo-agent-app]

Sepo pushed fixes for this PR. Branch: agent/implement-issue-228/codex-25779146548. Requested by @sepo-agent.

• Narrowed the early Resolve explicit route authorization precheck to only explicit non-issue /implement requests.
• Kept the final Resolve route step unchanged as the authoritative dispatch-policy gate.
• Updated the focused workflow test to assert the narrowed precheck condition.
• Verified with npm --prefix .agent run build && node --test .agent/dist/__tests__/envelope.test.js and git diff --check.

[sepo-agent-app]

Sepo is dispatching follow-up automation.

Source	Next	Target	Round	Status
fix-pr	review	PR #232	3 / 40	Dispatched

Reason: agent planner selected review: fix-pr succeeded on open PR #232, and the user explicitly asked to review after the minimum fix was implemented.

[sepo-agent-app]

Rubrics Review

Total Score	Verdict	Rubrics Scored
100	PASS	8

Dimension	Rubric	Result	Score	Evidence
coding_workflow / generic	Validate delegated route authorization	pass	8/8	The new early precheck in agent-router.yml is now scoped to should_respond, requested_route == 'implement', and target_kind != 'issue'; the final Resolve route step remains unchanged as the authoritative policy gate.
coding_workflow / generic	Prefer agent-derived decisions	pass	7/7	Explicit non-issue /implement metadata is generated through agent-implement-metadata.md, not a repo setting or command-tail heuristic.
coding_workflow / generic	Reuse existing code	pass	8/8	The PR reuses resolve-dispatch.js, run-agent-task, provider resolution, and buildRequestedRouteDecision rather than adding a separate auth or dispatch implementation.
coding_workflow / generic	Prefer explicit structured inputs	pass	7/7	Generated metadata is normalized from explicit issue_title / issue_body JSON fields via normalizeImplementIssueMetadata in triage.ts.
coding_workflow / generic	Keep docs in sync	pass	7/7	request-lifecycle.md and supported-workflows.md document generated tracking-issue metadata and fallback behavior.
coding_workflow / generic	Read docs and linked context first	pass	6/6	The current PR head reflects the PR discussion clarification: keep the final gate, narrow the precheck, and only protect generated tracking-issue metadata for non-issue /implement.
coding_workflow / generic	Make surgical changes	pass	8/8	The latest requested fix is limited to the precheck condition plus a focused workflow-contract test in envelope.test.ts.
coding_style / generic	Prefer simple implementations	pass	7/7	The final shape is a narrow precheck plus the existing final dispatch gate; no broader auth-model refactor or extra configuration was introduced.

Notes

• The minimum requested fix appears implemented: the early Resolve explicit route authorization step now only runs for explicit /implement on non-issue targets, so issue /implement and other explicit routes are not pulled into an extra precheck path.
• The final Resolve route step remains the canonical dispatch-policy gate, preserving the existing authorization model.
• No rubric-specific follow-up needed.

Findings

• INFO: I found no rubric-specific blocker. The current diff matches the clarified intent and keeps the change narrowly scoped.

Final Rubric Verdict

PASS

[sepo-agent-app]

AI Review Synthesis

Dual-agent review by Claude and Codex.
Requested by @lolipopshock.

Summary of PR/Issue

• PR Derive implement issue titles from command text #232 fixes weak tracking issue metadata for explicit /implement requests from PR/discussion contexts.
• Earlier versions copied command-tail text, but the requester clarified that Sepo should generate context-derived issue metadata instead.
• The current head uses a metadata-only prompt, keeps the final Resolve route step as the authoritative policy gate, and narrows the early precheck to explicit non-issue /implement.
• The latest fix also preserves the prior approve-reads trust-boundary change for metadata generation.

Review

The current PR head looks ready to ship. Codex found no issues, Claude only noted optional INFO-level cleanup, and rubrics review passed all applicable dimensions.

Issue	Severity	Description
No unresolved actionable issues	INFO	Current head 2a5a2bd matches the clarified PR discussion: the precheck is scoped to explicit non-issue /implement, the final dispatch gate remains authoritative, and the metadata prompt runs read-only.

Progress

• The rejected command-tail title behavior has been replaced by context-derived metadata generation.
• The prior inline concern about permission_mode: approve-all is addressed with approve-reads; that thread is already resolved.
• The latest requested minimum fix narrowed Resolve explicit route authorization to the metadata prompt path only.
• Current GitHub check Test Scripts / check is passing, and reviewer-reported git diff --check is clean.
• No new inline comments, replies, minimizations, or thread resolutions were performed in this synthesis.

Recommended Next Step

NO_AUTOMATED_ACTION: No unresolved actionable branch changes remain; this is ready for human merge decision.

Final Verdict

SHIP

Action Items

• No required branch changes.

[sepo-agent-app]

Rubrics Update

Updated agent/rubrics from PR #232.

Added one rubric:

• context-derived-artifact-metadata under rubrics/workflow/
• Captures the durable preference from PR Derive implement issue titles from command text #232: when automation creates user-facing tracking artifacts from terse commands, generate title/body from request plus target context rather than copying command text or using generic placeholders.

Skipped the later gate/precheck feedback as already covered by existing authorization, structured-input, and surgical-change rubrics.

Validation passed: validated 21 rubrics.