@zhuoyuezs/ml-platform 0.1.9 → 0.1.10

package/skills/feature-management/SKILL.md

@@ -1,480 +0,0 @@
----
-name: feature-management
-description: Manage projects, versioned business feature assets and their lifecycle, dataset rowsets and endpoint eligibility, and causal realtime row or sequence-context reads through the deployed ML Platform API using the ml-platform CLI installed with the same release. Use when a business user asks an agent to manage an empty Project, define or change Parameter source contracts, author/package/register an Operator wheel, define single-column Features, order a FeatureSet, create a DatasetManifest or catalog, inspect references, soft-delete or restore a Parameter/Feature/FeatureSet version, configure training/validation/test rowsets or abnormal-data endpoint exclusion, configure realtime freshness policy, run catalog dry-run/apply, build a dataset, fetch inference data, or inspect an artifact without downloading the platform source repository. Do not use for model training, Operator/Dataset deletion, image builds, or Kubernetes deployment.
----
-
-# Feature Management
-
-Build the public asset chain without bypassing its versioned contracts:
-
-```text
-Parameter -----> Feature
-Operator ------> Feature -> FeatureSet -> DatasetManifest -> DatasetArtifact
-```
-
-Treat `Recipe` and public `Feature.compute` as removed. Treat `computation_hash` as internal execution metadata, never as a business-managed asset.
-
-## Platform Role And Evidence Boundaries
-
-The ML Platform is a deterministic data-contract and data-delivery platform. It
-registers versioned source Parameters, runs approved deterministic Operators,
-orders single-column Features into FeatureSets, resolves DatasetManifests, and
-materializes batch DatasetArtifacts or serves one causal realtime inference row.
-It records versions, lineage, quality, missingness, freshness, and execution
-metadata so an algorithm project can consume data without owning source routing
-or cache details.
-
-This Skill does not train, evaluate, or serve models; own complete business feature
-engineering; provision arbitrary source tables; or administer Kubernetes and
-platform services. Training, evaluation and model packaging are handled by the
-separate `model-lifecycle-management` Skill; this scope limit is not a claim that
-the platform lacks those capabilities. Read
-[references/platform-capability-guide.md](references/platform-capability-guide.md)
-when the user needs the detailed platform boundary or evidence-level explanation.
-
-Keep these evidence rules active in every workflow:
-
-- Platform defaults and capabilities are not business evidence.
-- Dry-run, publish, resolve, build, metadata inspection, downloaded-file
-  inspection, and realtime fetch are separate evidence checkpoints; success at
-  one checkpoint does not imply success at the next.
-- `validation.ok=true` does not by itself prove source semantics, causal formula
-  correctness, Parquet contents, or numeric parity.
-- Dry-run, publish, and resolve may not detect a missing source relation. Do not
-  report source-backed success until build/fetch returns the required evidence,
-  and never rename a Parameter or remove fields merely to bypass a failed read.
-
-## Load The Right Context
-
-1. Resolve the Skill root as the directory containing this `SKILL.md`.
-2. Read [references/contracts.md](references/contracts.md) before creating or changing JSON assets.
-3. Read [references/operator-authoring.md](references/operator-authoring.md) whenever creating or changing Operator code or a wheel.
-4. Read [references/commands.md](references/commands.md) immediately before a platform CLI action: discovery, validation, publication, build, realtime fetch, or artifact download. A local-only draft that is forbidden to call the CLI does not need this reference.
-5. Use [assets/catalog-template](assets/catalog-template) as a copyable starting point for a new end-to-end catalog. Rename every `example_*` identifier and update every referenced path before validation.
-6. Read [references/platform-capability-guide.md](references/platform-capability-guide.md) only when selecting an asset type or explaining a platform capability. Do not load it merely to write a confirmed local draft; it is never evidence for unresolved business semantics.
-
-## Initialize The Client
-
-Use the `ml-platform` executable on `PATH` for every platform command. The formal npm release installs
-the CLI and this pure Skill together. The Skill does not contain a second CLI runtime, launcher, or
-installer. During repository development, provide the current JavaScript CLI through an isolated test
-`PATH`.
-
-Before any platform operation, verify the executable and its version:
-
-```bash
-command -v ml-platform
-ml-platform version
-```
-
-If the executable is missing or cannot start, stop and report that the ML Platform release installation is incomplete. Do not download a client, search for a repository checkout, or fall back to another executable.
-
-Before any server-profile discovery, dry-run, publication, build, or artifact
-operation, inspect the effective API configuration:
-
-```bash
-ml-platform show-config
-ml-platform --profile server health
-```
-
-Use the global `--profile server` form shown above, before the business
-command. Do not append `--profile` after a business command. Before discovery,
-check the installed release with `ml-platform --help` and the relevant
-subcommand's `--help`; CLI releases may differ in supported flags. In the
-deployed 0.6.x CLI, registry `list-*` commands emit JSON by default and do not
-accept a `--json` flag.
-
-If the installed release rejects the global `--profile server` form shown above,
-record the CLI syntax error and inspect `show-config`/subcommand help before
-retrying the same read-only command without that flag when supported. Do not
-switch clients or classify a syntax error as an API outage; keep each command
-separate so CLI compatibility remains distinguishable from network health.
-
-The effective API target is resolved in this order: explicit `--api-url`,
-`ML_PLATFORM_API_URL`, then the saved value written by `ml-platform configure`.
-If no target is configured, ask the user for an approved API URL before making
-server requests. Do not hardcode an environment-specific address in a Skill,
-catalog, or prompt. Keep database, MinIO, and source credentials out of commands;
-use the server's managed Secrets.
-
-Install and upgrade the CLI and Skill only through the explicit commands provided by `@zhuoyuezs/ml-platform`. Restart the Agent session after a successful Skill upgrade so the definition is reloaded. Never copy files over an installed Skill directory manually.
-
-## Establish Intent
-
-Collect only missing information. Do not invent a source table, source field, formula, time boundary, unit, valid range, missing-data rule, or owner.
-
-Confirm:
-
-- the target project (namespace) for the assets; use the built-in `default` only when the user has no dedicated project. After the target is confirmed, write its explicit `project` field in every Parameter, Operator, Feature, FeatureSet and DatasetManifest draft; never rely on the schema default. Reads and filters use the `--project` command option;
-- business meaning, stable asset names, owner, and intended consumers;
-- Parameter source adapter (`postgresql_direct`, `mysql_direct`,
-  `sqlserver_direct`, or `influxdb_direct`) and credential-free source mapping;
-- feature formula, exact Parameter dependencies, windows, inclusion rules, rounding, null behavior, and output dtype;
-- whether an approved Operator already implements the formula;
-- FeatureSet column order;
-- dataset mode, read policy, time range, grid, prediction horizon/cutoff contract, and explicit Parameter outputs;
-- named training/validation/test rowsets, abnormal windows, endpoint-policy scope,
-  and the model context lookback used to decide endpoint eligibility;
-- realtime freshness and missing-input policy when serving inference data;
-- target profile/API and whether the user authorizes publish and/or build actions.
-
-Separate preparation from mutation. Creating files and running local tests or `apply --dry-run` does not authorize publishing a wheel, changing the Registry, or submitting a build Job.
-
-Soft-delete and restore are separate Registry mutations. Before soft-deleting a
-Parameter, Feature, or FeatureSet version, inspect its lifecycle state and both
-direct and transitive references, report the affected immutable consumers, and
-obtain explicit authorization for the exact `project/name:version`. Supply an
-actor, reason, and stable idempotency key. Soft deletion preserves historical
-references and hashes but hides the version from normal discovery and prevents
-new consumers from binding it. Restore only after checking that all of the
-resource's own dependencies are active. Never describe these operations as
-physical deletion.
-
-A label such as "10-minute mean" confirms neither its input Parameter nor a
-complete formula. Before drafting an Operator or Feature, ask for the exact
-versioned input Parameter(s), or for an approved source contract from which
-they will be created. Do not infer an input from the Feature name or a similar
-existing asset.
-
-### Semantic Asset Review Gate
-
-Treat resource correctness as a separate gate from workflow correctness. Before
-creating Catalog JSON, write a local semantic asset review with one row per
-Parameter, Operator, Feature and Dataset field:
-
-```text
-asset_key | business_meaning | source/evidence | confirmed_by | unresolved | proposed_value
-```
-
-The review must distinguish three sources: confirmed business facts, facts
-observed from the selected Project Registry/CLI, and agent proposals. A Skill
-reference, schema default, similarly named old asset, or platform capability is
-not business evidence. Do not convert a proposal into `proposed_value` without
-explicit user confirmation or an exact match in the selected Project.
-
-Stop with `need_business_confirmation` when any required source mapping, field,
-unit, formula, time conversion, missing/quality policy, FeatureSet order,
-dataset read policy, rowset/endpoint policy, owner, or approval boundary is
-unresolved. Do not create placeholder Catalog files to make the workflow look
-complete.
-
-For a requested Feature, `exact Parameter dependencies` is an independent
-required contract item. If the user names a transform or window but not its
-input Parameter(s), include `input_parameter` in the unresolved questions and
-stop. Do this before treating an Operator formula as complete: a time window,
-cutoff rule, or Feature name never identifies the input.
-
-After confirmation, show the proposed dependency closure and obtain approval of
-the semantic asset plan before generating Catalog files. A successful local
-schema check or remote dry-run is not semantic approval.
-
-Before emitting or writing a draft, mechanically check that every asset carries
-the confirmed `project` field, that every Feature input carries that same
-`project`, and that every Operator `input_schema.parameters` reference is
-qualified as `project/parameter:version`. The schema's `default` values are not
-valid substitutes for an explicit non-default target. When a confirmed Feature
-config defines window closure, cutoff inclusion, duplicate handling, or empty
-window behavior, copy all of those fields into the Feature config rather than
-reducing it to the window string.
-
-## Discover Existing Assets
-
-Check the selected profile and list existing Parameter, Operator, Feature, FeatureSet, and Dataset versions before choosing names. Scope discovery to the target project with `--project`, because the true registry key is `project/name:version` and the same `name:version` may exist independently under another project. Run each `list-*` command as a separate command so one failed check cannot hide the status of the others. Do not add `--json` unless the installed subcommand help explicitly advertises it; supported releases emit machine-readable JSON by default. Registry list commands are paginated; search by stable identifier or follow every page until `offset + len(items) >= total`. Reuse an exact immutable version only when its full content matches. Never reference an asset in another project; cross-project references are rejected.
-
-CLI readiness is a hard gate for every Registry conclusion. If `command -v`,
-`version`, `show-config`, or server `health` fails, returns a nonzero status, or
-does not identify the intended target, stop with `platform_not_ready`. Do not
-list assets, select reuse versus authoring, dry-run, publish, build, fetch, or
-report a Registry fact from prompt text, a remembered response, or a similar
-local asset. Report the failed command and its configured target; resume only
-after the user/environment restores the same target.
-
-Create a new version when source semantics, formula code, config meaning, inputs, output dtype, time behavior, quality rules, or column order change. Never overwrite an immutable version or use suffixes such as `new`, `final`, or `test2`.
-
-### Operate An Existing Registered Dataset
-
-For diagnosis, resolve, build, Job lookup, and artifact lookup of an already
-registered DatasetManifest, use the API through `ml-platform`. Do not search the
-platform source checkout or a local Catalog directory for a matching JSON file.
-
-1. Run `show-config` and `health` to record the effective API source.
-2. Run `list-projects`, then `list-datasets --project <project>` to discover
-   candidates from the Registry.
-3. Ask the user to confirm the exact `project`, `dataset_id`, and
-   `dataset_version` when more than one valid candidate exists. Never infer a
-   target from a similar local filename.
-4. Run `get-dataset <dataset_id> <dataset_version> --project <project>` and
-   inspect the returned registered contract.
-5. Run `resolve-dataset` for a read-only dependency and manifest-hash check.
-6. Submit exactly one `build-registered-dataset ... --wait` only after the user
-   authorizes that exact registered version.
-7. Use the returned Job ID with `get-job`, then use the returned manifest hash
-   with `get-dataset-artifact` after success.
-
-Local `resolve-manifest` and `build-dataset <file>` remain authoring tools for a
-new or changed Catalog contract before it is registered. They are not required
-for operating an existing Registry version.
-
-## Upgrade Dependency Chains
-
-Treat a version change as a release of its affected reverse-dependency closure, not as an isolated asset bump.
-
-1. Record the intended old-to-new version mapping and the semantic reason for every changed asset.
-2. Follow exact references from the changed asset through every affected downstream consumer. For a Parameter change, publish a new Operator version when its input schema names that Parameter version, then new versions of every affected Feature, FeatureSet, and DatasetManifest. For an Operator change, start with its affected Features.
-3. Republish only the affected closure, but explicitly list and justify every downstream asset intentionally retained on an older dependency.
-4. Keep every reference exact. Never rewrite an existing immutable version, infer `latest`, or assume that increasing a Feature or FeatureSet version also upgrades its dependencies.
-5. Treat `apply --dry-run` as an existence and structural-compatibility check. It does not prove that the declared versions are the intended business release.
-
-Use this dependency order for an affected chain:
-
-```text
-Parameter -> Operator -> Feature -> FeatureSet -> DatasetManifest
-```
-
-## Build The Catalog
-
-Keep one business domain in one user-owned catalog directory:
-
-```text
-<catalog>/
-  catalog.json
-  parameters/
-  operators/
-  operator_package/
-  features/
-  feature_sets/
-  datasets/
-```
-
-Keep platform demos and V95 built-ins unchanged. Do not put unrelated business assets under `src/data_platform_demo/builtin_catalogs/v95`.
-
-### Define Parameters
-
-Use the platform-capability guide's asset table before choosing the resource
-type. For each Parameter record the business signal, exact source evidence,
-unit, time/availability semantics and missing policy in the semantic review.
-Never infer a source table, column, measurement, tag, unit or timezone from a
-Parameter name.
-
-Create one stable, versioned source contract for each independently readable value. Keep credentials out of JSON. Use only supported direct adapters (`postgresql_direct`, `mysql_direct`, `sqlserver_direct`, and `influxdb_direct`) and explicit source identity. The server supplies database DSNs from managed Secrets; never add them to CLI arguments or Catalog JSON. Put source data validity in `quality_rules`; put dataset-specific transformations in preprocess Operators.
-
-When the approved source contract supplies SQL, copy its query text and named
-parameters exactly into `source.sql`/`source.params`. Do not retype, beautify,
-rename an identifier, change a join key, or "simplify" an approved query while
-drafting. SQL whitespace may be formatted only when a reviewed formatter proves
-the token stream is unchanged; every source identifier and `<= %(end)s` boundary
-remains part of the Parameter contract.
-
-For SQL Parameters, the runtime contract is a single statement: use the exact
-`source.sql` field and a mapping under `source.params` for every named
-placeholder other than the reserved `start` and `end` window parameters. Do not
-use `source.parameters` (it is not a supported alias and may be silently
-dropped by older CLI/server releases). Do not leave a trailing semicolon; the
-deployed Worker rejects SQL containing multiple statements. Verify the resolved
-Parameter still contains the named params before authorizing a build.
-
-Use Parameter `rounding` when every consumer must receive the same fixed-point value. The platform applies `mode` (`half_up` or `half_even`) and `decimals` after source normalization and before quality checks, source caching, replay, and Operator execution. Prefer an unrounded source expression, do not repeat the same rounding in an Operator, and publish a new Parameter plus its affected reverse-dependency closure when the rule changes.
-
-Do not represent a rolling mean, lag, ratio, trend, or model input as a Parameter. Those are Features.
-
-### Define Operators
-
-First reuse a registered Operator if its version, input schema, output schema, formula semantics, and runtime contract match exactly.
-
-When a new Operator is required:
-
-1. Write a standalone pure-Python package with a `module:function` entrypoint.
-2. Make the Feature entrypoint accept one context and return a pandas DataFrame.
-3. Consume only declared `context.inputs` and `context.metric_frames`.
-4. Return `event_time` exactly equal to `context.target_times` plus the requested physical output columns.
-5. Implement explicit causal boundaries; never use future rows accidentally.
-6. Keep execution deterministic, network-free, credential-free, and bounded by `timeout_seconds`.
-7. Add formula, boundary, missing-value, requested-output, and ordering tests.
-8. Build a `py3-none-any` wheel and reference it from `catalog.json`.
-9. Leave `code_hash`, `package_uri`, and `code_artifact` null in the draft spec; catalog publication fills them from the uploaded wheel.
-
-Use a meaningful immutable `function_hash`. Change the Operator version whenever executable behavior changes.
-
-### Define Features
-
-Create one JSON file per single output column. Set the confirmed `project` on the
-Feature and on every nested Feature input; a FeatureInput without `project`
-silently targets `default`. Bind exactly one Operator version and physical
-`output_column`. List only the Parameter versions actually required by that
-column's formula.
-
-Features may share the same Operator and config. The planner will merge their exact inputs and call the Operator once per computation group. Do not duplicate every Operator input into every Feature merely to make schemas look uniform.
-
-### Define The FeatureSet
-
-Reference immutable Feature versions in the exact consumer column order. Keep the list nonempty and duplicate-free. Do not copy formulas, inputs, or Operator configuration into the FeatureSet.
-
-### Define The DatasetManifest
-
-For supervised datasets, read
-[references/supervised-datasets.md](references/supervised-datasets.md) before
-publishing the first version. Settle labels, clocks, split bindings and the final
-DataSchema before expensive training.
-
-Do not use DatasetManifest as a catch-all for unresolved semantics. Confirm the
-dataset purpose and consumer, then separately confirm the target grid, horizon,
-read policy, explicit Parameter outputs, rowset or rowset splits, abnormal windows and
-endpoint eligibility. Keep the semantic asset review beside the draft Catalog
-so a reviewer can compare business decisions with generated fields.
-
-Reference exactly one FeatureSet. Use `parameters` only for Parameter columns that must also appear explicitly in `parameter_dataset.parquet`; Feature dependencies are resolved automatically.
-
-Map the current Manifest schema exactly rather than carrying descriptive fields
-from Parameter, Feature, or FeatureSet into it. A target Parameter reference is
-**nested**; never flatten its `version` or `project` onto `target`:
-
-```json
-"target": {
-  "parameter": {"parameter": "hot_metal_si", "version": "v1", "project": "<project>"},
-  "si_time_source": "dispatch_time",
-  "offset_minutes": 20,
-  "interpolation": {"method": "linear"}
-}
-```
-
-`target.interpolation` is `{"method": "linear"}`, `{"method": "none"}` or
-`{"method": "forward_fill"}` -- neither it nor `target.parameter` accepts a
-bare string. The current DatasetManifest has no top-level `owner`,
-`description`, `si_null_policy`, or `preserve_all_candidate_rows`. Map a
-business statement only to an existing schema field (for example `mark_only`,
-`endpoint_policy`, a Feature config, or a Parameter missing policy); otherwise
-keep it in the semantic review and ask for a platform/schema change. Validate
-the generated object against the current schema before running `apply --dry-run`.
-
-When a confirmed missing-data policy applies to a Feature-only Parameter, put it
-in `parameter_missing_policies`, using `parameter`, `version`, `project`, and
-`policy`. Do not copy the `ParameterRequest` names `name` and `missing_policy`
-into that list. Omit the section when no such policy is confirmed.
-
-Declare one dataset-wide `prediction` contract when Features use a forecast cutoff. Operators consume `context.cutoff_times`; do not copy the same prediction horizon into every Feature config. Check the selected Operator's `input_schema.prediction` limits and satisfy an explicit-horizon requirement before publishing or building.
-
-Use `snapshot` for reproducible training data, `as_of` for historical visibility replay, and `latest` for current inference-style reads. Use a fresh `dataset_version` when validating a new release or intentionally requesting a new immutable dataset contract.
-
-Treat row construction and endpoint eligibility as separate contracts. Use
-`rowset_splits` to label candidate target instants such as `training`,
-`validation`, and `test`. When abnormal observations should make only selected
-endpoints unusable, keep `abnormal_windows.policy=mark_only` and declare
-`endpoint_policy`; do not delete canonical Feature rows. Declare
-`endpoint_policy.context_lookback` from the model sequence contract, independently
-of Operator source-history requirements. Read [references/contracts.md](references/contracts.md)
-for the cutoff formula, half-open overlap boundaries, scope behavior, and
-`rowset_membership.parquet` schema.
-
-For realtime inference, declare `realtime_fetch` only when its effective policy
-must be part of the contract; leaving it unset preserves existing manifest
-hashes. Keep `allow_missing=false` unless the user explicitly accepts missing
-required inputs. Read [references/contracts.md](references/contracts.md) for the
-freshness, tail-edge, gap-fill, and rowset contracts.
-
-## Validate Before Publishing
-
-Run, in order:
-
-1. Semantic asset review: no required unresolved field and every proposed value has a source or user confirmation.
-2. Operator unit tests. Before building, turn every applicable item in
-   `operator-authoring.md` into a separately named test; do not let one broad
-   happy-path assertion substitute for cutoff-before/at/after, duplicate and
-   missing input, empty history, requested-output, event-time order, or
-   dtype/rounding coverage. The template is only a starting point.
-3. Wheel build and wheel filename verification.
-4. Catalog path, schema, dependency, immutability, and package validation with `apply --dry-run` against the same target profile intended for publication.
-5. Compare the catalog's exact dependency closure with the intended old-to-new version mapping. Reject any affected downstream reference that still points to an old version unless its retention is explicit and justified.
-6. A human-readable summary of planned new, unchanged, retained, and conflicting assets.
-
-Stop on any error. Do not weaken schema validation, fabricate a missing dependency, change an existing version in place, or switch profiles to make validation pass.
-
-## Publish And Build
-
-Publish only after the user explicitly approves Registry and wheel changes. Use catalog `apply` so publication follows Parameter -> Operator -> Feature -> FeatureSet -> Dataset order.
-
-After publication, resolve every new DatasetManifest and compare its exact Parameter, Operator, Feature, and FeatureSet versions with the pre-publication mapping. Stop if an affected old key or any unexpected version remains. Resolve the manifest before building. Submit a build only when requested. For the current partitioned materialization runtime, use `--max-parallelism 1` unless a separately verified platform capability says otherwise; do not retry or resubmit a failed Job until its error and already-completed partitions are understood. For server builds, wait for the terminal Job state and download the exact artifact by `dataset_id + manifest_hash`.
-
-Do not delete versioned Registry assets, cancel Jobs, rebuild images, modify Kubernetes, or change service configuration as part of this workflow unless the user separately and explicitly requests that action. An empty Project may be soft-deleted only on an explicit request; rely on the server to reject deletion when resources still exist.
-
-## Fetch Realtime Inference Data
-
-Use `fetch-inference-data` only when the user requests one causal-cutoff read.
-Confirm the cutoff and prediction horizon. The command must call
-`POST /inference-data/fetch`; it must not submit a batch build, write parquet, or
-publish a DatasetArtifact.
-
-Verify that the response reports the requested cutoff and derived target time,
-`uses_post_cutoff_data=false`, `contract.manifest_hash`, a replayable `as_of`
-manifest, and per-Parameter freshness evidence. Report tolerated missing or
-gap-filled inputs as degraded freshness, not as a normal read.
-
-## Verify The Artifact
-
-Treat Registry metadata inspection and downloaded-file inspection as separate
-checkpoints. A successful `get-dataset-artifact` can establish the immutable
-identity, object inventory, row count, validation summary, and lineage metadata;
-it cannot establish Parquet schema, column order, or file-content hashes. If a
-download times out, report whether no response/progress was observed or whether
-some body bytes were received, preserve the metadata-only evidence, and leave
-downloaded-file validation explicitly incomplete.
-
-Require all of the following before reporting success:
-
-- Job status is `succeeded`;
-- `validation.json` has `ok: true` and no errors;
-- `validation.feature_nulls` is read, not skipped: `ok: true` can coexist with
-  null model inputs reported as warnings. Report `total_null_cells`, and for each
-  affected Feature its `null_count`, event-time range, and upstream Parameter
-  keys. Set `output.strict_feature_nulls` when any null should fail the build
-  instead;
-- row count is nonzero and matches the requested half-open time grid when no
-  documented row filtering applies. When `abnormal_windows` uses a drop policy,
-  reconcile the lower count against `abnormal_windows.rows_before`,
-  `rows_after`, and `dropped_rows` in the resolved manifest. With `mark_only`,
-  require `dropped_rows=0` and preserve the full candidate rowset;
-- when `endpoint_policy` is set, require `abnormal_windows.policy=mark_only`,
-  preserve every candidate row in `feature_dataset.parquet` and
-  `parameter_dataset.parquet`, and require `rowset_membership.parquet`;
-- verify membership counts globally and by rowset, inspect every ineligible
-  row's `reason_codes`, and confirm that the configured compatibility column in
-  both canonical datasets equals `policy_applied AND eligible`; it is false for
-  pass-through rowsets outside the policy scope;
-- for a partitioned build, verify that merged membership, endpoint-policy
-  quality statistics, lineage, and `policy_hash` match a single build of the
-  same manifest;
-- `feature_dataset.parquet` starts with `event_time`, optional `furnace_id`, then FeatureSet columns in exact order;
-- resolved lineage records every Parameter version, Feature version, Operator version, code hash, and computation hash, exactly matches the approved dependency-version mapping, and contains no stale affected key;
-- artifact lineage contains the same approved dependency closure as the resolved manifest;
-- execution metadata shows the expected number of computation groups and requested physical columns;
-- when `source_read` is set, `latency_stats.fetch_timing_summary` shows the chunk
-  windows tiling the fetch range, and any retries are accounted for;
-- missing values and warnings are reported, not silently repaired.
-
-The manifest hash returned by `resolve-manifest` or `resolve-dataset` is the artifact key: it stays
-the same after the build, so it is usable for cache reuse and polling before
-submission. Distinguish the two lookup failures rather than treating both as "not
-ready" — `422` with `invalid_artifact_key` means the key can never name an
-artifact, while `404` with `artifact_not_found` or `artifact_not_built` means
-nothing is built under a valid key, and lists any in-flight Jobs.
-
-State the current runtime truth: first-phase public builds execute registered Python Operators through `FeatureOperatorRunner`. Do not claim that Chronon compile/backfill or Chronon-native feature computation occurred unless the artifact contains and passes those explicit execution records.
-
-## Report The Outcome
-
-Return a concise business-facing summary containing:
-
-```text
-catalog and version
-new / unchanged assets by type
-planned versus resolved dependency versions and any explicitly retained old versions
-Operator package filename and SHA-256
-FeatureSet and ordered feature count
-dataset id, version, manifest hash, and Job id
-row and column counts
-rowset candidate / policy-applied / eligible / ineligible counts when endpoint_policy is declared
-validation status, warnings, and missing-data summary
-artifact location
-actual compute backend
-```
-
-If the work stops before publication, distinguish generated files, locally validated files, dry-run validation, and remotely published assets.

package/skills/feature-management/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "特征与实时取数管理"
-  short_description: "管理版本化 Parameter、Operator、Feature、数据集与实时推理取数"
-  default_prompt: "Use $feature-management to manage versioned feature assets, build datasets, or fetch one causal realtime inference row through the platform API."

package/skills/feature-management/assets/catalog-template/catalog.json

@@ -1,23 +0,0 @@
-{
-  "schema_version": "ml_data_platform.catalog/v1",
-  "name": "example_business_feature_catalog",
-  "version": "v1",
-  "parameters": [
-    "parameters/example_temperature.v1.json"
-  ],
-  "operators": [
-    {
-      "spec": "operators/example_temperature_features.v1.json",
-      "package": "operator_package/dist/business_feature_operator_template-1.0.0-py3-none-any.whl"
-    }
-  ],
-  "features": [
-    "features/example_temperature_mean_5m.v1.json"
-  ],
-  "feature_sets": [
-    "feature_sets/example_temperature_core.v1.json"
-  ],
-  "datasets": [
-    "datasets/example_temperature_training.v1.json"
-  ]
-}

package/skills/feature-management/assets/catalog-template/datasets/example_temperature_training.v1.json

@@ -1,40 +0,0 @@
-{
-  "schema_version": "ml_data_platform.dataset_manifest/v1",
-  "project": "replace_with_project",
-  "dataset_id": "example_temperature_training",
-  "dataset_version": "v1",
-  "mode": "training",
-  "read_policy": "snapshot",
-  "time_range": {
-    "start": "2026-07-01T00:00:00+08:00",
-    "end": "2026-07-02T00:00:00+08:00",
-    "grid": "10min"
-  },
-  "prediction": {
-    "horizon": "0min"
-  },
-  "rowset": {
-    "strategy": "fixed_grid",
-    "grid": "10min"
-  },
-  "parameters": [],
-  "parameter_missing_policies": [
-    {
-      "parameter": "example_temperature",
-      "version": "v1",
-      "project": "replace_with_project",
-      "policy": "report_only"
-    }
-  ],
-  "feature_set": {
-    "name": "example_temperature_core",
-    "version": "v1"
-  },
-  "preprocess": [],
-  "output": {
-    "format": "parquet",
-    "include_stats": true,
-    "include_lineage": true,
-    "engine": "chronon"
-  }
-}

package/skills/feature-management/assets/catalog-template/feature_sets/example_temperature_core.v1.json

@@ -1,14 +0,0 @@
-{
-  "schema_version": "ml_data_platform.feature_set/v1",
-  "project": "replace_with_project",
-  "name": "example_temperature_core",
-  "version": "v1",
-  "features": [
-    {
-      "name": "example_temperature_mean_5m",
-      "version": "v1"
-    }
-  ],
-  "owner": "replace_with_business_owner",
-  "description": "Ordered example temperature features."
-}

package/skills/feature-management/assets/catalog-template/features/example_temperature_mean_5m.v1.json

@@ -1,28 +0,0 @@
-{
-  "schema_version": "ml_data_platform.feature/v1",
-  "project": "replace_with_project",
-  "name": "example_temperature_mean_5m",
-  "version": "v1",
-  "inputs": [
-    {
-      "parameter": "example_temperature",
-      "version": "v1",
-      "project": "replace_with_project"
-    }
-  ],
-  "operator": "example_temperature_features",
-  "operator_version": "v1",
-  "config": {
-    "window": "5min",
-    "window_closed": "right",
-    "cutoff_included": true,
-    "post_cutoff_allowed": false,
-    "duplicate_event_time": "last",
-    "empty_window": "null"
-  },
-  "output_column": "example_temperature_mean_5m",
-  "output_dtype": "float64",
-  "offline_online_supported": false,
-  "owner": "replace_with_business_owner",
-  "description": "Mean example temperature in the causal interval (target-5min, target]."
-}

package/skills/feature-management/assets/catalog-template/operator_package/pyproject.toml

@@ -1,12 +0,0 @@
-[build-system]
-requires = ["hatchling"]
-build-backend = "hatchling.build"
-
-[project]
-name = "business-feature-operator-template"
-version = "1.0.0"
-requires-python = ">=3.10"
-dependencies = ["pandas>=2.3.3"]
-
-[tool.hatch.build.targets.wheel]
-packages = ["src/business_feature_operator_template"]

package/skills/feature-management/assets/catalog-template/operator_package/src/business_feature_operator_template/__init__.py

@@ -1,39 +0,0 @@
-"""Example business Feature Operator. Replace names and formulas before use."""
-
-from __future__ import annotations
-
-from typing import Any
-
-import pandas as pd
-
-
-SUPPORTED_OUTPUTS = {"example_temperature_mean_5m"}
-
-
-def compute_features(context: Any) -> pd.DataFrame:
-    requested = list(dict.fromkeys(context.requested_output_columns))
-    unknown = sorted(set(requested) - SUPPORTED_OUTPUTS)
-    if unknown:
-        raise ValueError(f"unsupported output columns: {unknown}")
-
-    input_keys = {item.parameter: item.key for item in context.inputs}
-    parameter_key = input_keys.get("example_temperature")
-    if parameter_key is None:
-        raise ValueError("example_temperature input is required")
-
-    frame = context.metric_frames[parameter_key]
-    values = pd.to_numeric(
-        frame.set_index("timestamp")["value"],
-        errors="coerce",
-    ).sort_index()
-    if values.index.has_duplicates:
-        values = values.groupby(level=0).last()
-
-    window = pd.Timedelta(str(context.config["window"]))
-    output: dict[str, object] = {"event_time": context.target_times}
-    if "example_temperature_mean_5m" in requested:
-        output["example_temperature_mean_5m"] = [
-            values.loc[(values.index > target - window) & (values.index <= target)].mean()
-            for target in context.target_times
-        ]
-    return pd.DataFrame(output)