Re-scope author super-skill to feature level (al-feature-author)

Turn the object-granularity al-object-author super-skill into the
feature/PR-level al-feature-author - the true authoring counterpart of
al-code-review, which takes a whole PR. feature-spec in -> whole-PR
code-artifact out.

- microsoft/skills/author/al-feature-author.md (renamed from
  al-object-author.md): takes inputs [feature-spec]; decomposes it into a
  cross-referenced object graph, allocates a contiguous object-ID block,
  applies the mandatory affix, resolves cross-object references (API page
  SourceTable = authored master), fans each derived object-spec out to the
  worklisted leaves, rolls up their artifacts, reconciles the refs, and
  enumerates the objects no current leaf authors (List/Card pages,
  permission set, install codeunit) as open-questions. Worked example:
  a Membership feature -> 3 artifacts (master table + setup table from
  al-table-author, API page from al-api-page-author) rolling up to completed.
- skills/do.md (composition v1.1, STABLE-CONTRACT): add feature-spec to the
  standard inputs; extend Relevance so a super-skill's inputs need not equal
  its leaves' - it may derive the leaves' inputs by decomposing its own;
  generalize Action rollup to findings-report OR code-artifact. Review
  (findings) semantics read identically - behavior-preserving.
- .github/scripts/validate_frontmatter.py: add feature-spec to STANDARD_INPUTS.
  #67 R26 generalization unchanged.
- README.md, agent-consumption.md: author family's top-level skill is now
  al-feature-author.

The al-table-author leaf and the R26 generalization from #67 are unchanged.
Knowledge article count unchanged at 199.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

skills/do.md

@@ -43,7 +43,7 @@ application-area: [all]
 
 `bc-version`, `technologies`, `countries`, `application-area` are optional filters that let an orchestrator pre-select applicable skills for a task. They follow the same semantics as in READ.
 
-`inputs` is a list of abstract input types the skill **accepts**. Standard values: `pr-diff`, `object-list`, `file-path`, `repository`, `telemetry-query`, `object-spec`. `object-spec` is an abstract description of the BC object(s) to generate — the target table, the desired entity naming, the fields to expose, the read-only flag, and any other generation parameters — supplied by the orchestrator for authoring tasks (the authoring counterpart to a review skill's `pr-diff`). Semantics are any-of: the orchestrator supplies whichever listed input types it has, and the skill is invoked with a non-empty subset of its declared `inputs`. A skill that cannot proceed with the supplied subset MUST return `outcome: "not-applicable"`. `outputs` is always a single-element list naming the output kind; two output kinds are defined: `findings-report` (review skills) and `code-artifact` (authoring skills).
+`inputs` is a list of abstract input types the skill **accepts**. Standard values: `pr-diff`, `object-list`, `file-path`, `repository`, `telemetry-query`, `object-spec`, `feature-spec`. `object-spec` is an abstract description of the BC object(s) to generate — the target table, the desired entity naming, the fields to expose, the read-only flag, and any other generation parameters — supplied by the orchestrator for authoring tasks (the authoring counterpart to a review skill's `pr-diff`). `feature-spec` is an abstract description of a whole BC feature — its entities, their relationships, the surfaces (pages and APIs) to expose, and any generation parameters — from which a feature author **derives** the individual `object-spec`s it feeds to its leaf sub-skills. Semantics are any-of: the orchestrator supplies whichever listed input types it has, and the skill is invoked with a non-empty subset of its declared `inputs`. A skill that cannot proceed with the supplied subset MUST return `outcome: "not-applicable"`. `outputs` is always a single-element list naming the output kind; two output kinds are defined: `findings-report` (review skills) and `code-artifact` (authoring skills).
 
 `sub-skills` is an optional field. When present and non-empty, the skill is a **super-skill** that composes other action skills; see *Composition* below. Values are repo-relative paths to action-skill files.
 
@@ -299,9 +299,9 @@ Composition is flat: a super-skill MAY list only leaf skills (skills without the
 The five required sections still apply. Their meaning shifts from knowledge files to sub-skills:
 
 - `## Source` — names the sub-skills invoked (mirrors `sub-skills` in frontmatter).
-- `## Relevance` — rules for deciding which sub-skills apply to the current task. A sub-skill is relevant when its declared `inputs` are satisfied by the orchestrator's provided inputs and the orchestrator has not disabled it via configuration. The super-skill MUST NOT filter sub-skills by task content (for example, by inspecting the diff or the file). Task-level applicability is the sub-skill's own responsibility; sub-skills signal non-applicability by returning `outcome: "not-applicable"` or `outcome: "no-knowledge"`.
+- `## Relevance` — rules for deciding which sub-skills apply to the current task. A sub-skill is relevant when its declared `inputs` are satisfied — either directly by the orchestrator's provided inputs, or by inputs the super-skill itself will supply by decomposing its own input — and the orchestrator has not disabled it via configuration. A super-skill's own `inputs` need not equal its leaves' `inputs`; when they differ (for example, a feature author declares `inputs: [feature-spec]` while its leaves declare `inputs: [object-spec]`), the super-skill's `## Action` decomposes its own input into the inputs its leaves require, and relevance is judged against those derived inputs. The super-skill MUST NOT filter sub-skills by task content (for example, by inspecting the diff or the file). Task-level applicability is the sub-skill's own responsibility; sub-skills signal non-applicability by returning `outcome: "not-applicable"` or `outcome: "no-knowledge"`.
 - `## Worklist` — the final list of sub-skills to invoke; the rest go to `skipped-sub-skills`.
-- `## Action` — invoke each worklisted sub-skill with the appropriate subset of inputs, collect its findings-report verbatim into `sub-results`, and copy its `findings[]` into the super-skill's top-level `findings[]` with `from-sub-skill` set. Findings from a sub-skill with `outcome: "failed"` MUST NOT be copied into the super-skill's top-level `findings[]` and MUST NOT contribute to the super-skill's `summary.counts` (their report is still preserved in `sub-results` for traceability, consistent with DO's rule that consumers ignore a failed skill's findings).
+- `## Action` — invoke each worklisted sub-skill with the appropriate subset of inputs (a super-skill whose `inputs` differ from its leaves' derives those leaf inputs here), collect its report verbatim into `sub-results`, and roll its results up into the super-skill's top-level list according to the output kind. For a `findings-report`, copy its `findings[]` into the super-skill's top-level `findings[]` with `from-sub-skill` set. For a `code-artifact`, copy its `artifacts[]` into the super-skill's top-level `artifacts[]` (the `code-artifact` schema has no per-artifact `from-sub-skill` field, so leaf attribution is preserved through `sub-results`). In both cases a sub-skill with `outcome: "failed"` contributes nothing to the super-skill's top-level list (`findings[]` or `artifacts[]`) and MUST NOT contribute to the super-skill's `summary.counts` (its report is still preserved in `sub-results` for traceability, consistent with DO's rule that consumers ignore a failed skill's output).
 - `## Output` — the super-skill's output contract, including `sub-results` and, if any, `skipped-sub-skills`.
 
 ### Outcome rollup