gitlab prompt generator: normalizeGitLabTaskConfig accepts unknown task-level properties and an unvalidated 'gitlab' field

Start in src/prompt-generators/gitlab/config.ts, reading assertGitLabTaskConfig, normalizeGitLabTaskConfig, and the existing assertGitLabSearchParams validation. Add validation for task-level properties and gitlab constructor options, then add regression coverage for an unknown task key, a non-object gitlab value, and an unknown gitlab property; done means these cases are rejected consistently with the schema.

Observed behavior

normalizeGitLabTaskConfig / assertGitLabTaskConfig in src/prompt-generators/gitlab/config.ts validate gitlab.search thoroughly (via assertKnownProperties and per-field assertions), but the task-level wrapper itself is only partially validated:

• The task config object is never passed through assertKnownProperties. Typo'd or stale top-level properties (e.g. promptTemplete, searc, gitLab) are silently accepted, with no error or warning.
• The optional gitlab field, typed as GitLabConstructorOptions ({ origin?: string; token?: string; tokenEnv?: string; userAgent?: string }), is not validated at all. Any value, including non-objects (gitlab: 42, gitlab: \"https://gl.test\") or objects with bogus / extra fields (gitlab: { origin: 12345, tokenZ: \"secret\" }), passes the assertion and is handed straight to new GitLab(this.#task.gitlab) in GitLabPromptGenerator.generate.

This is inconsistent with the schema and with how gitlab.search is validated:

• schema/loop-the-loop.schema.json declares additionalProperties: false for both gitlabTask and gitlabConstructorOptions, and requires origin / token / tokenEnv / userAgent to be strings.
• assertGitLabSearchParams already uses assertKnownProperties to reject unknown search fields. The task level should match.

This is the GitLab-side mirror of issue #45 (the equivalent gap in src/prompt-generators/github/config.ts) and issue #49 (the same shape in src/prompt-generators/bugzilla/config.ts).

Expected behavior

assertGitLabTaskConfig should reject unknown task-level properties and validate the optional gitlab field, so that programmatic callers (and any path that bypasses the AJV-validated CLI schema) get the same protection as schema-validated configs. Recommended additions:

• assertKnownProperties(value, ['gitlab', 'search', 'promptTemplate'], 'gitlab').
• A new helper to validate gitlab when present: confirm it is a record, call assertKnownProperties(gl, ['origin', 'token', 'tokenEnv', 'userAgent'], 'gitlab.gitlab'), and run assertOptionalString on each of origin, token, tokenEnv, userAgent.

Minimal reproduction

import { normalizeGitLabTaskConfig } from 'loop-the-loop/prompt-generators/gitlab/config';

// All three of these are silently accepted today, but the schema rejects them:
normalizeGitLabTaskConfig({
  search: { project: 'gitlab-org/gitlab' },
  promptTemplate: 'Issue {{id}}',
  promptTemplete: 'typo - silently dropped',           // unknown task field
});

normalizeGitLabTaskConfig({
  search: { project: 'gitlab-org/gitlab' },
  promptTemplate: 'Issue {{id}}',
  gitlab: 'https://gitlab.example.com',                // wrong type - should be object
});

normalizeGitLabTaskConfig({
  search: { project: 'gitlab-org/gitlab' },
  promptTemplate: 'Issue {{id}}',
  gitlab: { origin: 'https://gitlab.example.com', tokenZ: 'typo' },  // typo'd key
});

Running these against dist/prompt-generators/gitlab/config.js confirms all three return objects typed as GitLabTask. The typo'd properties either survive on the returned object (where downstream code never reads them) or get forwarded to the GitLab SDK constructor unchecked.

Suggested fix

Bring gitlab/config.ts into line with the schema and with the level of validation already applied to gitlab.search:

function assertGitLabTaskConfig(value: unknown): asserts value is GitLabTask {
  if (!isRecord(value)) {
    throw new Error('gitlab task config must be an object');
  }

  assertKnownProperties(
    value,
    ['gitlab', 'search', 'promptTemplate'],
    'gitlab',
  );

  assertRequiredString(value, 'promptTemplate', 'gitlab.promptTemplate');

  if ('gitlab' in value) {
    assertGitLabConstructorOptions(value['gitlab']);
  }

  const search = value['search'];
  if (!isRecord(search)) {
    throw new Error('gitlab.search must be an object');
  }
  assertGitLabSearchParams(search);
}

function assertGitLabConstructorOptions(value: unknown): void {
  if (!isRecord(value)) {
    throw new Error('gitlab.gitlab must be an object');
  }
  assertKnownProperties(
    value,
    ['origin', 'token', 'tokenEnv', 'userAgent'],
    'gitlab.gitlab',
  );
  assertOptionalString(value, 'origin', 'gitlab.gitlab.origin');
  assertOptionalString(value, 'token', 'gitlab.gitlab.token');
  assertOptionalString(value, 'tokenEnv', 'gitlab.gitlab.tokenEnv');
  assertOptionalString(value, 'userAgent', 'gitlab.gitlab.userAgent');
}

Regression tests should cover: a typo'd task-level key, a non-object gitlab, and a gitlab object with an unknown property.

Severity

S3: the symptom is silent acceptance of broken / stale configuration. Programmatic callers and any path that bypasses the AJV schema check see no error; the misconfigured field is either dropped or forwarded to the SDK, producing surprising downstream behavior.