bugzilla prompt generator: normalizeBugzillaTaskConfig accepts unknown task-level properties and an unvalidated 'bugzilla' field

Start in src/prompt-generators/bugzilla/config.ts and compare its task-level checks with schema/loop-the-loop.schema.json and the existing bugzilla.search validation. Add regression coverage for an unknown task key, a non-object bugzilla value, and an unknown or wrongly typed constructor option; done means each invalid configuration is rejected consistently.

Observed behavior

normalizeBugzillaTaskConfig / assertBugzillaTaskConfig in src/prompt-generators/bugzilla/config.ts validate bugzilla.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, bugZilla) are silently accepted and dropped on the spread, with no error or warning.
• The optional bugzilla field, typed as BugzillaConstructorOptions ({ origin?: string; apiKey?: string }), is not validated at all. Any value, including non-objects (bugzilla: 42, bugzilla: "https://bz.test") or objects with bogus / extra fields (bugzilla: { origin: 12345, apiKy: "secret" }), passes the assertion and is handed straight to new Bugzilla(this.#task.bugzilla) in BugzillaPromptGenerator.generate.

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

• schema/loop-the-loop.schema.json declares additionalProperties: false for both bugzillaTask and bugzillaConstructorOptions, and requires origin / apiKey to be strings.
• assertBugzillaSearchParams already uses assertKnownProperties to reject unknown search fields. The task level should match.

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

Expected behavior

assertBugzillaTaskConfig should reject unknown task-level properties and validate the optional bugzilla 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, ['bugzilla', 'search', 'promptTemplate'], 'bugzilla').
• A new helper to validate bugzilla when present: confirm it is a record, call assertKnownProperties(bz, ['origin', 'apiKey'], 'bugzilla.bugzilla'), and run assertOptionalString on each of origin and apiKey.

Minimal reproduction

import { normalizeBugzillaTaskConfig } from 'loop-the-loop/prompt-generators/bugzilla/config';

// All three of these are silently accepted today, but the schema rejects them:
normalizeBugzillaTaskConfig({
  search: { product: 'Core' },
  promptTemplate: 'Bug {{id}}',
  promptTemplete: 'typo - silently dropped',           // unknown task field
});

normalizeBugzillaTaskConfig({
  search: { product: 'Core' },
  promptTemplate: 'Bug {{id}}',
  bugzilla: 'https://bugzilla.example.com',            // wrong type - should be object
});

normalizeBugzillaTaskConfig({
  search: { product: 'Core' },
  promptTemplate: 'Bug {{id}}',
  bugzilla: { origin: 12345, apiKy: 'secret' },        // wrong-typed origin + typo'd apiKey
});

In all three cases the function returns a value typed as BugzillaTask, but the runtime object either drops valid configuration (the typo cases) or smuggles invalid values through to the Bugzilla SDK constructor.

Suggested fix

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

function assertBugzillaTaskConfig(
  value: unknown,
): asserts value is BugzillaTask {
  if (!isRecord(value)) {
    throw new Error('bugzilla task config must be an object');
  }

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

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

  if ('bugzilla' in value) {
    assertBugzillaConstructorOptions(value['bugzilla']);
  }

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

function assertBugzillaConstructorOptions(value: unknown): void {
  if (!isRecord(value)) {
    throw new Error('bugzilla.bugzilla must be an object');
  }
  assertKnownProperties(value, ['origin', 'apiKey'], 'bugzilla.bugzilla');
  assertOptionalString(value, 'origin', 'bugzilla.bugzilla.origin');
  assertOptionalString(value, 'apiKey', 'bugzilla.bugzilla.apiKey');
}

Regression tests should cover: a typo'd task-level key, a non-object bugzilla, and a bugzilla 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.