Decide task policy for reserved Git environment variables #104

Currently, PR #102 strips repo-context and Git config control variables from the environment used by task setup, baseline, agent, and target commands. That is the right defensive move for base-only workspace isolation, but it creates a separate policy question for task-authored environment values: if a task YAML explicitly declares variables such as GIT_DIR, GIT_WORK_TREE, GIT_CONFIG_COUNT, or GIT_CONFIG_GLOBAL, should the runner silently strip them, reject the task as invalid, or document them as reserved?

Why this should not be handled in #102:

• Implement base-only trial workspaces #102 is scoped to base-only workspace materialization and reference verification.
• Promoting this into task schema/docs/prompt semantics would expand the contract beyond ADR 0010.
• The implementation PR already has a safe defensive behavior; the missing piece is a durable task-env policy.

Follow-up decision needed:

• Decide whether reserved Git control env keys are unsupported task YAML values.
• If yes, add task validation that rejects them and update the relevant task/environment docs.
• If no, adjust the runner contract so trusted task-authored env is applied intentionally, with clear safety boundaries.

Suggested validation:

• A task declaring reserved Git env keys either fails validation with a clear error or has documented behavior covered by a focused task execution test.

Source:

• Raised during the review-loop for PR Implement base-only trial workspaces #102 while checking Git env isolation for issue Use base-only git workspaces for all agent trials #90.