x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/utils.ts (1)

38-43: Use inline type modifier for type-only imports.

The import mixes value imports (Streams, isSchema) with type-only imports (ClassicFieldDefinition, FieldDefinition). Per coding guidelines, type-only imports should use import type.

♻️ Suggested fix using inline type imports

-import {
-  Streams,
-  isSchema,
-  type ClassicFieldDefinition,
-  type FieldDefinition,
-} from '@kbn/streams-schema';
+import {
+  Streams,
+  isSchema,
+} from '@kbn/streams-schema';
+import type { ClassicFieldDefinition, FieldDefinition } from '@kbn/streams-schema';

Alternatively, if the codebase prefers inline type modifiers (TypeScript 4.5+):

import {
  Streams,
  isSchema,
  type ClassicFieldDefinition,
  type FieldDefinition,
} from '@kbn/streams-schema';

As per coding guidelines: "Use import type for type-only imports in TypeScript."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/utils.ts`
around lines 38 - 43, The import currently mixes runtime values (Streams,
isSchema) with types (ClassicFieldDefinition, FieldDefinition); update the
import to mark the type-only imports with the inline type modifier so the line
imports Streams and isSchema as normal values and imports ClassicFieldDefinition
and FieldDefinition as types (use "type ClassicFieldDefinition" and "type
FieldDefinition" in the same import) to satisfy the coding guideline requiring
type-only imports be declared with import type.

x-pack/platform/plugins/shared/streams_app/test/scout/ui/fixtures/page_objects/streams_app.ts (1)

821-829: Add explicit Promise<void> return types to the new page-object methods.

These helpers are part of the exported StreamsApp API, so the new methods should declare their return types explicitly for consistency with the repo rule. As per coding guidelines "Prefer explicit return types for public APIs and exported functions in TypeScript."

Also applies to: 931-939

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/test/scout/ui/fixtures/page_objects/streams_app.ts`
around lines 821 - 829, The new page-object method
confirmChangesInReviewModalIfPresent should declare an explicit Promise<void>
return type (i.e., change its signature to
confirmChangesInReviewModalIfPresent(): Promise<void>) to comply with the
exported StreamsApp API typing rule; update this method and the other new helper
method(s) introduced in the same file around the other diff (the methods shown
in the 931-939 range) to similarly declare explicit Promise<void> return types
so the public/page-object API has consistent explicit return types.

x-pack/platform/plugins/shared/streams/server/lib/content/stream/helpers.test.ts (1)

11-60: Add a typeless description-only case here.

These tests cover typed fields, but the new feature is a typeless override like { description, from }. Since withoutInheritedFieldMetadata() now sits on the export path for doc-only overrides, it would be worth locking in that it preserves description while stripping inherited metadata for a field with no type.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams/server/lib/content/stream/helpers.test.ts`
around lines 11 - 60, Add a new unit test in the
describe('withoutInheritedFieldMetadata') suite that verifies a typeless,
description-only field (e.g. { description: 'desc', from: 'logs.parent' }) is
returned with description preserved and inherited metadata stripped; call
withoutInheritedFieldMetadata with an input like { 'doc.only': { description:
'desc', from: 'logs.parent' } } and assert the result equals { 'doc.only': {
description: 'desc' } } so the function (withoutInheritedFieldMetadata) handles
fields that lack a type.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/state_management/simulation_state_machine/types.ts (1)

66-72: Narrow docOnlyOverrides to the doc-only shape.

Lines 66-72 document that this bag must only hold typeless documentation overrides, but FieldDefinition also admits mapped field configs. That makes it easy for a future reducer to stash a typed field here and have it flow through the doc-only path accidentally. Prefer a dedicated shape such as Record<string, { description?: string }> or the narrowest exported typeless field-definition type.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/state_management/simulation_state_machine/types.ts`
around lines 66 - 72, The docOnlyOverrides property is currently typed as
FieldDefinition which permits full typed/mapped field configs; narrow it to a
dedicated typeless shape to prevent typed field configs flowing into the
doc-only path—replace the type of docOnlyOverrides (in types.ts) with a specific
shape such as Record<string, { description?: string }> or use the project’s
exported “typeless” field-definition type if one exists; update any related
exports/consumers (references to docOnlyOverrides) to the new type so reducers
and helpers enforce only documentation-only entries.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/types.ts (1)

23-24: Consider renaming PersistableSchemaFieldType to avoid confusion.

The JSDoc above notes that 'system' and 'unmapped' are pseudo-types that "must never be persisted as real mapping types." However, PersistableSchemaFieldType is defined as an alias of SchemaFieldType, which includes these pseudo-types. This creates a naming contradiction—the type name suggests these values can be persisted, but they shouldn't be.

Consider either:

• Renaming to something like UISchemaFieldType to clarify it's for UI purposes only
• Or narrowing PersistableSchemaFieldType to exclude the pseudo-types:

  export type PersistableSchemaFieldType = NonNullable<FieldDefinitionConfig['type']>;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/types.ts`
around lines 23 - 24, PersistableSchemaFieldType currently aliases
SchemaFieldType which includes pseudo-types 'system' and 'unmapped' that must
not be persisted; change PersistableSchemaFieldType to only include real mapping
types by narrowing it to NonNullable<FieldDefinitionConfig['type']> (i.e.
exclude 'system' and 'unmapped'), and keep SchemaFieldType as the UI union that
includes the pseudo-types so callers that need persistable-only types use
PersistableSchemaFieldType while the UI continues to use SchemaFieldType.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/page_content.tsx (1)

356-359: Consider memoizing the getChanges result to avoid duplicate computation.

getChanges(schemaEditorFields, definitionFields) is computed twice - once in openConfirmationModal (Line 261) and again in the onConfirm prop (Line 357). While the performance impact is likely negligible for typical field counts, memoizing this result would be cleaner.

♻️ Suggested refactor

+  const mappingChanges = React.useMemo(
+    () => getChanges(schemaEditorFields, definitionFields),
+    [schemaEditorFields, definitionFields]
+  );
+
   const openConfirmationModal = () => {
-    const changes = getChanges(schemaEditorFields, definitionFields);
-    if (changes.length === 0) {
+    if (mappingChanges.length === 0) {
       // If there are no mapping-affecting changes, skip the review modal entirely.
       void saveChanges();
       return;
     }
     // ... rest of function
   };

   // Later in ManagementBottomBar:
   onConfirm={
-    schemaEditorFields.length > 0 &&
-    getChanges(schemaEditorFields, definitionFields).length > 0
+    mappingChanges.length > 0
       ? openConfirmationModal
       : saveChanges
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/page_content.tsx`
around lines 356 - 359, Compute the diff once and reuse it: create a memoized
value (e.g. pendingChanges = useMemo(() => getChanges(schemaEditorFields,
definitionFields), [schemaEditorFields, definitionFields])) and replace the two
direct calls to getChanges(...) (the one used inside openConfirmationModal and
the one in the onConfirm prop selection) with this pendingChanges; ensure you
import/use React.useMemo and update the conditional that currently chooses
between openConfirmationModal and saveChanges to reference pendingChanges.length
> 0.

x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/validate_fields.test.ts (1)

38-93: Add regression coverage for the descendant-side relaxation.

These new cases cover validateAncestorFields(), but the matching validateDescendantFields() change in validate_fields.ts still has no test for doc-only fields. A small pair of cases there would keep both directions aligned.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/validate_fields.test.ts`
around lines 38 - 93, Add tests mirroring the ancestor-side cases for the
descendant-side validator: in validate_fields.test.ts add two it() cases that
call validateDescendantFields() (same style as the existing
validateAncestorFields tests) — one where an ancestor defines a doc-only field
(no type, only description) and the descendant supplies a real type, and another
where the descendant supplies a real type plus a description. Use the same
helpers (createWiredStreamDefinition) and streamName ('logs.otel') and assert
that validateDescendantFields({... ancestors: [ancestor], fields, streamName })
does not throw; name the tests to indicate they cover "doc-only" ancestor fields
and the descendant relaxation.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/schema_editor_table.tsx (1)

27-28: Prefer @emotion/react for the new description-cell styles.

This change pulls in @emotion/css just for one cell renderer. Keeping the styles on the css prop / @emotion/react path avoids mixing Emotion APIs in the same React file and stays aligned with the rest of the EUI styling stack.

As per coding guidelines, "Use @elastic/eui components with Emotion (@emotion/react) for styling in React."

Also applies to: 204-216

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/schema_editor_table.tsx`
around lines 27 - 28, The file schema_editor_table.tsx imports and uses
`@emotion/css` for the description-cell styles; replace that by using
`@emotion/react`'s css prop to stay consistent with EUI/Emotion usage: remove the
import from '@emotion/css', import the css (and/or jsx pragma if needed) from
'@emotion/react', and update the description cell renderer (the description-cell
code around lines ~204-216 / any function like renderDescriptionCell or the JSX
element that currently uses css(...)) to apply styles via the JSX css prop (e.g.
<div css={css`...`}> or pass the css object to the css prop) instead of calling
the `@emotion/css` helper; ensure any className generated by css(...) is converted
to the css prop usage and that getStreamTypeFromDefinition and other imports
remain unchanged.

x-pack/platform/plugins/shared/streams/server/routes/internal/streams/schema/route.test.ts (1)

52-63: Good coverage, consider adding a test for fields with both type and description.

The test suite covers the key filtering scenarios well. Consider adding a test case verifying that fields with both a valid type and a description are preserved (not accidentally filtered):

it('preserves fields with both type and description', () => {
  const fields: NamedFieldDefinitionConfig[] = [
    { name: 'attributes.a', type: 'keyword', description: 'has both' },
  ];
  const result = __test__.getSimulatableFieldDefinitions(fields);
  expect(result).toEqual([{ name: 'attributes.a', type: 'keyword', description: 'has both' }]);
});

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams/server/routes/internal/streams/schema/route.test.ts`
around lines 52 - 63, Add a unit test to ensure getSimulatableFieldDefinitions
preserves fields that include both a valid type and a description: in
route.test.ts add a case (similar to existing ones) that passes a
NamedFieldDefinitionConfig like { name: 'attributes.a', type: 'keyword',
description: 'has both' } to __test__.getSimulatableFieldDefinitions and assert
the returned array contains the same object (including description) to verify
the function does not drop the description field.

x-pack/platform/packages/shared/kbn-streams-schema/src/fields/index.test.ts (1)

191-213: Minor: Tests at Lines 191-196 and 207-213 overlap.

Both tests verify that isMappingProperties returns false when fields contain description-only entries (no type). Consider consolidating these into a single test or differentiating them more clearly (e.g., one for explicitly missing type, one for undefined type).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@x-pack/platform/packages/shared/kbn-streams-schema/src/fields/index.test.ts`
around lines 191 - 213, The two tests using isMappingProperties that both assert
false for description-only fields are redundant; consolidate them into one
clearer test (e.g., "should return false for doc-only/undefined type fields")
that covers both cases: a field with only description (no type key) and a field
with type explicitly set to undefined, using the same FieldDefinition objects
and a single expect(isMappingProperties(...)).toBe(false) assertion, and remove
the duplicate test block (the ones with descriptions 'should return false for
description-only overrides (no type)' and 'should return false when containing
doc-only fields (description without type)').

x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/validate_fields.ts (1)

140-149: Use direct descendant lookup here too.

Lines 146-149 still rescan descendant.ingest.wired.fields for every field. Matching the ancestor path with a keyed lookup keeps the two validators symmetric and avoids repeated Object.entries() allocations.

♻️ Proposed refactor

       if (!Object.hasOwn(fields, fieldName)) {
         continue;
       }
       const fieldType = fields[fieldName].type;
+      const descendantField = descendant.ingest.wired.fields[fieldName];
       if (
         fieldType !== undefined &&
-        Object.entries(descendant.ingest.wired.fields).some(
-          ([descendantFieldName, attr]) =>
-            descendantFieldName === fieldName && attr.type !== undefined && attr.type !== fieldType
-        )
+        descendantField?.type !== undefined &&
+        descendantField.type !== fieldType
       ) {
         throw new MalformedFieldsError(
           `Field ${fieldName} is already defined with incompatible type in the child stream ${descendant.name}`
         );
       }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/validate_fields.ts`
around lines 140 - 149, The loop currently rescans
descendant.ingest.wired.fields with Object.entries(...) for each fieldName;
replace that repeated allocation with a direct keyed lookup: get const
descendantField = descendant.ingest.wired.fields[fieldName] (or check
Object.hasOwn to be safe) and then compare descendantField.type !== undefined &&
descendantField.type !== fieldType, keeping the existing guards (the surrounding
Object.hasOwn(fields, fieldName) and fieldType checks) and using the same
fieldName, fields, descendant, and descendant.ingest.wired.fields symbols so the
validator becomes symmetric and avoids repeated Object.entries allocations.

x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/validate_fields.test.ts (1)

38-93: Add the inverse doc-only inheritance regression too.

These cases cover parent doc-only -> child typed, but the primary feature path is also parent typed -> child description-only override. A matching validateDescendantFields no-conflict case would also lock down the new fieldType === undefined branch.

🧪 Suggested test additions

   describe('type validation', () => {
+    it('should allow description-only override when parent already maps the field', () => {
+      const ancestor = createWiredStreamDefinition('logs', {
+        'attributes.field1': { type: 'keyword' },
+      });
+
+      const fields = {
+        'attributes.field1': { description: 'Child documentation' },
+      };
+
+      expect(() =>
+        validateAncestorFields({
+          ancestors: [ancestor],
+          fields,
+          streamName: 'logs.otel',
+        })
+      ).not.toThrow();
+    });
+
     it('should allow same type with description override', () => {
       const ancestor = createWiredStreamDefinition('logs', {
         'attributes.field1': { type: 'keyword' },
@@
 describe('validateDescendantFields', () => {
+  it('should allow description-only updates when a descendant already maps the field', () => {
+    const descendants = [
+      createWiredStreamDefinition('logs.child', {
+        'attributes.level': { type: 'keyword' },
+      }),
+    ];
+    const fields: FieldDefinition = {
+      'attributes.level': { description: 'Updated docs' },
+    };
+
+    expect(() => validateDescendantFields({ descendants, fields })).not.toThrow();
+  });
+
   it('should throw when field type conflicts with descendant', () => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams/server/lib/streams/helpers/validate_fields.test.ts`
around lines 38 - 93, Add the complementary regression test for the inverse path
(parent has a real type, child supplies only a description) by creating a case
that uses validateDescendantFields (mirroring the existing ancestor tests) to
assert no-throw when a parent stream defines 'attributes.field1' with type
'keyword' and the descendant/child defines only description (no type). Use the
same helpers (createWiredStreamDefinition) and test structure as the existing
type validation tests, target the branch that handles fieldType === undefined,
and ensure the test calls validateDescendantFields with
ancestors/fields/streamName analogous to the current validateAncestorFields
tests.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_actions.tsx (1)

144-161: Consider consolidating duplicate "Edit field" action definitions.

Lines 149-154 and the fallback at line 157 both add an "Edit field" action with identical behavior (openFlyout({ isEditingByDefault: true })). Consider reusing the pre-defined editFieldAction for both branches to reduce duplication.

Proposed simplification

       case 'unmapped':
         actions = [viewFieldAction];
-        // Only show "Edit field" if the parent doesn't have a real ES mapping (type !== 'unmapped')
-        // If the parent has a real mapping, the child can't map it differently
-        if (!hasRealMappingInParent) {
-          actions.push({
-            name: i18n.translate('xpack.streams.actions.editFieldLabel', {
-              defaultMessage: 'Edit field',
-            }),
-            onClick: () => openFlyout({ isEditingByDefault: true }),
-          });
-        } else {
-          // If parent has real mapping, only allow editing description
-          actions.push(editFieldAction);
-        }
+        // Edit field is always available - the flyout handles restrictions based on parent mappings
+        actions.push(editFieldAction);
         if (field.description) {
           actions.push(clearDescriptionAction);
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_actions.tsx`
around lines 144 - 161, The branch handling 'unmapped' currently pushes a
duplicate inline "Edit field" action that calls openFlyout({ isEditingByDefault:
true }) and also pushes editFieldAction in the else branch; replace the inline
action with the existing editFieldAction to eliminate duplication. Locate the
'unmapped' case where viewFieldAction, hasRealMappingInParent, openFlyout and
clearDescriptionAction are used and change the push of the inline Edit field
action to push(editFieldAction) so both branches reuse the same editFieldAction
definition.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_type.tsx (1)

14-14: Consider adding explicit return type for exported component.

Per coding guidelines, exported functions should have explicit return types for better maintainability and API clarity.

Proposed change

-export const FieldType = ({ type, aliasFor }: { type: FieldTypeOption; aliasFor?: string }) => {
+export const FieldType = ({ type, aliasFor }: { type: FieldTypeOption; aliasFor?: string }): React.ReactElement => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_type.tsx`
at line 14, The exported component FieldType lacks an explicit return type;
update its signature to include one (e.g., annotate as : JSX.Element or use
React.FC<{ type: FieldTypeOption; aliasFor?: string }>) so the export has a
clear, explicit return type; modify the declaration of FieldType (which accepts
props type: FieldTypeOption and optional aliasFor) to include the chosen return
type.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/flyout/index.tsx (1)

111-131: Consider extracting complex boolean derivations to named functions for readability.

The derived state logic is correct but dense. The inline comments help, but extracting these to small helper functions could improve readability:

const isDescriptionOnlyEditing = computeIsDescriptionOnlyEditing(isEditing, streamType, field.status, isDescriptionOnlyMode);

This is a minor readability suggestion; the current implementation is functionally correct.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/flyout/index.tsx`
around lines 111 - 131, Extract the dense boolean derivations into small named
helper functions to improve readability: create functions such as
computeIsDescriptionOnlyEditing(isEditing, streamType, fieldStatus,
isDescriptionOnlyMode), computeHasDescriptionChanged(field, nextField),
computeIsInheritedDescriptionOnlyEditing(isDescriptionOnlyEditing, fieldStatus)
and computeIsUnmappedDescriptionOnlyChange(isEditing, streamType, fieldStatus,
fieldType, nextFieldType, hasDescriptionChanged) and replace the inline
expressions for isDescriptionOnlyEditing, hasDescriptionChanged,
isInheritedDescriptionOnlyEditing, isDocOnlyField and
isUnmappedDescriptionOnlyChange with calls to these helpers (use the existing
symbols: isDescriptionOnlyEditing, hasDescriptionChanged,
isInheritedDescriptionOnlyEditing, isDocOnlyField,
isUnmappedDescriptionOnlyChange and field/status/type/nextField variables to
wire inputs).

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/types.ts (1)

24-24: Consider whether PersistableSchemaFieldType alias adds value.

The alias PersistableSchemaFieldType = SchemaFieldType doesn't narrow the type—it's identical to SchemaFieldType. If the intent is to represent types safe for persistence, it should exclude pseudo-types:

export type PersistableSchemaFieldType = Exclude<SchemaFieldType, 'system' | 'unmapped'>;

If this is intentional (e.g., for future disambiguation), consider adding a JSDoc comment explaining the purpose.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/types.ts`
at line 24, PersistableSchemaFieldType is currently a direct alias of
SchemaFieldType and doesn't add value; update its definition to explicitly
exclude non-persistable pseudo-types or document intent. Change the type alias
PersistableSchemaFieldType to exclude 'system' and 'unmapped' (using
Exclude<SchemaFieldType, 'system' | 'unmapped'>) so it represents only
persistable types, or if you want to keep the alias as-is for future use, add a
JSDoc above PersistableSchemaFieldType explaining why it mirrors SchemaFieldType
and when it will diverge.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/page_content.tsx (1)

355-359: Consider extracting the changes check to avoid duplication.

The getChanges(schemaEditorFields, definitionFields).length > 0 check appears both here (line 357) and in openConfirmationModal (line 262). While currently consistent, this could be memoized to avoid redundant computation and reduce the risk of divergence.

♻️ Optional: Memoize the changes check

+  const mappingChanges = React.useMemo(
+    () => getChanges(schemaEditorFields, definitionFields),
+    [schemaEditorFields, definitionFields]
+  );
+
   const openConfirmationModal = () => {
-    const changes = getChanges(schemaEditorFields, definitionFields);
-    if (changes.length === 0) {
+    if (mappingChanges.length === 0) {
       // If there are no mapping-affecting changes, skip the review modal entirely.
       void saveChanges();
       return;
     }
     // ... rest of function
   };

   // ... later in JSX
   onConfirm={
-    schemaEditorFields.length > 0 &&
-    getChanges(schemaEditorFields, definitionFields).length > 0
+    schemaEditorFields.length > 0 && mappingChanges.length > 0
       ? openConfirmationModal
       : saveChanges
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/page_content.tsx`
around lines 355 - 359, Extract the repeated changes check into a memoized
boolean (e.g., hasChanges) computed with useMemo(() =>
getChanges(schemaEditorFields, definitionFields).length > 0,
[schemaEditorFields, definitionFields]) and replace both occurrences (the
onConfirm ternary and the check inside openConfirmationModal) to use hasChanges;
this avoids duplicate getChanges calls and prevents divergence while keeping
existing behavior when invoking openConfirmationModal or saveChanges.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/flyout/field_summary.tsx (1)

246-247: ⚠️ Potential issue | 🟡 Minor

Preserve multiline descriptions in read-only mode.

Line 247 still renders the saved description as a plain string, so any newline entered in the textarea collapses after leaving edit mode. Render the read-only value inside an element with white-space: pre-wrap so the summary matches what the user entered.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/flyout/field_summary.tsx`
around lines 246 - 247, The read-only description branch currently renders
`${field.description ?? EMPTY_CONTENT}` as a plain string, which collapses
newlines; update the read-only rendering in the FieldSummary component to wrap
the description (or EMPTY_CONTENT fallback) in a container element that applies
CSS white-space: pre-wrap so multiline text preserves line breaks—target the JSX
branch that references field.description and EMPTY_CONTENT and replace the plain
string with that wrapped element.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_actions.tsx (1)

147-164: Remove duplicate inline action definition.

Lines 152-157 define an inline "Edit field" action that's identical to the editFieldAction constant defined at lines 107-112. Both branches (if (!hasRealMappingInParent) and else) push functionally equivalent actions.

♻️ Simplify by using `editFieldAction` in both branches

       case 'unmapped':
         actions = [viewFieldAction];
-        // Only show "Edit field" if the parent doesn't have a real ES mapping (type !== 'unmapped')
-        // If the parent has a real mapping, the child can't map it differently
-        if (!hasRealMappingInParent) {
-          actions.push({
-            name: i18n.translate('xpack.streams.actions.editFieldLabel', {
-              defaultMessage: 'Edit field',
-            }),
-            onClick: () => openFlyout({ isEditingByDefault: true }),
-          });
-        } else {
-          // If parent has real mapping, only allow editing description
-          actions.push(editFieldAction);
-        }
+        // Edit field is always available - if parent has real mapping, 
+        // the flyout restricts editing to description only
+        actions.push(editFieldAction);
         if (field.description) {
           actions.push(clearDescriptionAction);
         }

If the behavior should differ between the two branches, that distinction should be documented or handled via props passed to the flyout.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_actions.tsx`
around lines 147 - 164, The inline "Edit field" action defined inside the
'unmapped' case duplicates the existing editFieldAction constant; replace the
inline action pushed in the if (!hasRealMappingInParent) branch with the
existing editFieldAction so both branches push editFieldAction (and remove the
duplicate inline object), and if you need different behavior pass a flag into
openFlyout or adjust editFieldAction to call openFlyout({ isEditingByDefault:
true, ... }) based on hasRealMappingInParent; locate edits around
editFieldAction, openFlyout, hasRealMappingInParent, viewFieldAction and
clearDescriptionAction in the 'unmapped' case.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/state_management/stream_enrichment_state_machine/utils.test.ts (2)

22-37: Keep these fixtures type-checked instead of double-casting through unknown.

as unknown as StreamEnrichmentContextType disables the compiler right where this test should catch shape drift in StreamEnrichmentContextType and simulatorRef.getSnapshot(). A typed helper or satisfies on the minimal surface used by getUpsertFields() keeps the fixture honest without widening everything to unknown.

Suggested tightening

-      const context = {
+      const context = {
         definition: wiredDefinition,
         simulatorRef: {
           getSnapshot: () => ({
             context: {
               detectedSchemaFields: [
                 { name: 'foo', parent: 'wired-stream', status: 'unmapped' },
                 { name: 'keep', parent: 'wired-stream', status: 'mapped', type: 'date' },
               ],
               docOnlyOverrides: {
                 foo: { description: 'Foo description' },
               },
             },
           }),
         },
-      } as unknown as StreamEnrichmentContextType;
+      } satisfies Pick<StreamEnrichmentContextType, 'definition' | 'simulatorRef'>;
 
-      const result = getUpsertFields(context);
+      const result = getUpsertFields(context as StreamEnrichmentContextType);

As per coding guidelines, "Use TypeScript for all new code; avoid any and unknown."

Also applies to: 54-66

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/state_management/stream_enrichment_state_machine/utils.test.ts`
around lines 22 - 37, The fixture is being double-cast through unknown which
disables type-checking; instead make the test fixture conform to
StreamEnrichmentContextType (or the minimal shape used by getUpsertFields) so
the compiler validates it—replace the "as unknown as
StreamEnrichmentContextType" with either a properly typed helper factory or use
TypeScript's "satisfies" on the object, ensuring simulatorRef.getSnapshot()
returns the correctly typed snapshot shape and the context variable is typed as
StreamEnrichmentContextType so getUpsertFields() will be type-checked by the
compiler.

---

73-73: Drop the JSON serialization assertion here.

expect(result).toEqual({ foo: { description: 'Foo description' } }) already fails if foo.type is present, so the JSON.stringify(...) check is redundant and less precise. If you want the explicit guard, assert the property structurally.

More direct assertion

-      expect(JSON.stringify(result)).not.toContain('"type":"unmapped"');
+      expect(result.foo).not.toHaveProperty('type');

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/stream_detail_enrichment/state_management/stream_enrichment_state_machine/utils.test.ts`
at line 73, Remove the redundant JSON serialization assertion in the test:
delete the line using
expect(JSON.stringify(result)).not.toContain('"type":"unmapped"') and rely on
the existing structural assertion expect(result).toEqual({ foo: { description:
'Foo description' } }); if you want an explicit guard instead, add a structural
check such as expect(result.foo).not.toHaveProperty('type') referencing the
result variable in the utils.test.ts test case.

x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_actions.tsx (1)

148-164: Redundant conditional: both branches add the same action.

The if-else at lines 151-161 performs identical operations in both branches — both add an "Edit field" action with the same i18n key and the same openFlyout({ isEditingByDefault: true }) call. The inline action in the if branch is functionally identical to the predefined editFieldAction.

This can be simplified to unconditionally push editFieldAction.

♻️ Suggested simplification

       case 'unmapped':
         actions = [viewFieldAction];
-        // Only show "Edit field" if the parent doesn't have a real ES mapping (type !== 'unmapped')
-        // If the parent has a real mapping, the child can't map it differently
-        if (!hasRealMappingInParent) {
-          actions.push({
-            name: i18n.translate('xpack.streams.actions.editFieldLabel', {
-              defaultMessage: 'Edit field',
-            }),
-            onClick: () => openFlyout({ isEditingByDefault: true }),
-          });
-        } else {
-          // If parent has real mapping, only allow editing description
-          actions.push(editFieldAction);
-        }
+        // Edit action allows mapping (if no parent ES mapping) or editing description (if parent has mapping)
+        actions.push(editFieldAction);
         if (field.description) {
           actions.push(clearDescriptionAction);
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/public/components/data_management/schema_editor/field_actions.tsx`
around lines 148 - 164, The if-else that checks hasRealMappingInParent is
redundant because both branches push an identical "Edit field" action; replace
the entire conditional with a single unconditional actions.push(editFieldAction)
to simplify the logic—locate where actions is initialized (actions =
[viewFieldAction]) and remove the block that creates an inline action calling
openFlyout({ isEditingByDefault: true }), relying instead on the existing
editFieldAction (and still conditionally push clearDescriptionAction if
field.description is present).

x-pack/platform/plugins/shared/streams_app/test/scout/ui/fixtures/page_objects/streams_app.ts (1)

821-831: Add explicit return types to these new page-object APIs.

These helpers are part of the public StreamsApp surface, so it would be better to declare Promise<void> explicitly instead of relying on inference.

♻️ Proposed change

-  async confirmChangesInReviewModalIfPresent() {
+  async confirmChangesInReviewModalIfPresent(): Promise<void> {

-  async fillFieldDescription(description: string) {
+  async fillFieldDescription(description: string): Promise<void> {

-  async clickEditFieldButton() {
+  async clickEditFieldButton(): Promise<void> {

As per coding guidelines, "Prefer explicit return types for public APIs and exported functions in TypeScript."

Also applies to: 933-941

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@x-pack/platform/plugins/shared/streams_app/test/scout/ui/fixtures/page_objects/streams_app.ts`
around lines 821 - 831, The new page-object APIs (e.g., the async method
confirmChangesInReviewModalIfPresent in streams_app.ts and the other similar
helpers mentioned around lines 933-941) should declare explicit return types;
update each public async method signature to include Promise<void> (for example:
async confirmChangesInReviewModalIfPresent(): Promise<void>) so the StreamsApp
public surface uses explicit return types instead of relying on inference.