Review useful list contents with existing projections

[raghubetina]

Current status — 2026-09-26

The useful-list-content authoring decision is still pending. Scalar collection projections already exist; this is not a request to build a duplicate capability. The September 19 source/public-lifecycle proof below remains scoped to its exact Plan.

The bounded Service documentation correction merged in Service PR #854 at 2b44fff43e486706c1db709fa15b41d8c8d03064. The Candidate input example now names rejected index mutation inputs, bindings, and return destination instead of index projections. This correction was checked against source, schema, and existing tests; local docs checks, focused independent review, and current-candidate hosted CI passed. It adds no new public-lifecycle or preview claim.

Remaining work

• Decide whether the agent should propose/read back useful list contents with the existing projection vocabulary.
• Correct the stale Service Candidate input example for index projection serialization (Service #854).
• Reconcile the September 22 index-projection warning against its exact source and emitted behavior before claiming a general Analyzer defect.
• Qualify an approved richer projection with populated narrow-screen preview.

New supporting evidence: the September 22 assisted Reading List trial selected Author/Finished but omitted book titles, and a normal Rails edit corrected the list. It also records an Analysis warning about index projection despite those fields being emitted. Reconcile that exact warning/source path before claiming a new general Analyzer defect or duplicate feature. This trial supports the importance of list contents but does not settle the authoring policy.

Earlier scope and research (historical; the status above governs remaining work)

Parent: Ben/Jelani feedback decision tracker #43. Research recommendations remain pending unless a prior decision is explicitly identified.

Review the facts that make list rows distinguishable

Decision packet; recommendation pending. Covers observation 46. Suggested owner: the Skills compact Plan-review issue #79, cross-linked from Drawing Board #26. Rendering organization is already approved under #709; optional interactive filters are separately tracked in #736.

Original evidence

Trial 4's baseline 2826e4b selects four indexes with authorization and ordering only—none includes projection. HabitLog and Reminder use the associated Habit's name as Primary Descriptor. Thus multiple logs/reminders for one Habit look identical in the list until opened.

The later index-content commit 3d492b9 adds logged_on/note to HabitLog rows and reminder date/scheduled time/status to Reminder rows. Adding the date/time/status addresses useful distinction. The note is still subject to the separate unwanted-field decision; it is not a reason to keep a field the user rejected.

This is not evidence that Primary Descriptors must be unique or that the Compiler should append every stored field to every index. A human-facing record label and a useful collection presentation are different choices.

Current support, history, and fresh proof

The ordinary Plan already has ordered collection projections. Inside HabitLog's scaffold:

{
  "index": {
    "authorization": "public",
    "ordering": "habit_log.recent_first",
    "projection": [
      { "association": "habit_log.habit", "authorization": "public" },
      { "field": "habit_log.logged_on" }
    ]
  }
}

The association line retains the Habit descriptor; the scalar line distinguishes the occurrence. This exact combined snippet is source-supported but was not separately runtime-qualified in this task. The fresh executable check deliberately used only the second line to establish ordinary scalar index admission independently of association behavior. A selected projection does not automatically add the descriptor; authors must select the intended contents explicitly.

ScaffoldLowering lowers admitted Fields in authored order; WebScaffoldFiles renders those index projection items. Generic exact-source lowering entered with #500 / 4855a23b on August 25, before the colleague trial.

Fresh September 19 local public lifecycle: source b079cd2, Ruby 4.0.6, isolated PostgreSQL 18. Starting from the exact trial4 baseline, only habit_log.scaffold.index.projection: [{field: "habit_log.logged_on"}] was added. Normal import, Analysis job, Compilation Start and Execute succeeded. The emitted artifact contains 265 files and 14 gaps; its index reads habit_log.logged_on. Submitted bytes are preserved. All 14 ordered semantic gap records are identical to the original trial4 baseline (not merely the same count). No projection gap occurs; the selected named Ordering retains its pre-existing target gap and id fallback. The structural Plan comparison confirms that adding /application/entities/2/scaffold/index/projection is the only authored-meaning change; the probe reserializes JSON. Manifest SHA-256: 796f8311d17c3ac0ada237e81901c25cb235b97f836154b4fceb07ed14684837. The task-owned cluster was stopped/deleted after the 28.31-second check.

There is a stale assertion in compiler.md's Candidate input paragraph: index projections are described as impossible through import. That contradicts current public lifecycle evidence. Tests against a legacy reduced input without exact submitted source are not evidence that current public Compilation rejects the feature. Correct the paragraph; do not open a new generalized-projection feature from the old report.

Conventions and prior art

Rails' pinned scaffold partial renders the supplied non-password attributes and its index renders each record partial. Rails does not mandate descriptor-only rows; applications are expected to edit these ordinary views.

GOV.UK tables emphasize comparing/scanning relevant information, and Carbon data tables distinguish basic display from optional search, sorting, and expansion. Neither means every app needs a data grid. The user has already chosen entity/context-specific Rails partials under #709; preserve that decision.

Options

1. Have the agent propose/read back useful contents using existing projections (recommended). For occurrence records, show identifying relationship plus date/time/status where relevant. Ask only consequential questions; routine presentation can be delegated and shown in the compact review.
2. Compiler automatically includes all fields. Reduces authoring, but adds noise, can expose unsuitable/internal data, and conflicts with explicitly selected projections. It is a new semantic default requiring its own deliberate decision.
3. Always keep descriptor-only and fix every app after Compile. Smallest initial Plan, but repeats a demonstrated usability problem and wastes an existing supported feature.

Owner question: Should Plan review include the proposed visible facts for each main list, with the agent using existing projections to make repeated records distinguishable?

Acceptance checks

• Trial4-shaped HabitLog and Reminder lists show distinct dates/times/status as approved, without restoring the rejected Note.
• The read-back shows selected contents and any omitted content; a deliberate descriptor-only list remains allowed.
• Order and authorization are preserved. Unsupported children are disclosed; the UI is not silently widened to fields or relationships the owner did not select.
• Correct the stale Compiler paragraph, add/reuse a public-lifecycle behavioral regression for scalar index projection, and retain current gap semantics.
• Run the exact accepted richer projection through Compilation and a populated browser preview at narrow width before claiming its full visual usability. The local generation-only check above does not establish that last boundary.

[raghubetina]

Current source check at Service ac29a2556e9ae8b0eb30ae50961f2cb93a560833 confirms the documentation contradiction remains: docs/architecture/design/compiler.md:184–187 describes index projection items as unreachable through import, while PlanSerializer#definition_data (515–528) serializes them. The rejected index children are mutation inputs, bindings and return destinations. This agrees with the earlier public-lifecycle proof already recorded here.

A smallest documentation-only correction is assigned after Service #848's independent evidence-routing fix lands. It will not change the pending useful-list-content authoring decision, Plan grammar, or emitted behavior. Current source/tests will be checked; no new broad application qualification is implied.

[raghubetina]

The bounded Service documentation correction is merged in Service PR #854 at 2b44fff43e486706c1db709fa15b41d8c8d03064. Final head 77d6138702bf6f681116e6308ac465201ca93947 was based on 5f5c625e4bde2d6677453bf44cdb480b8822a159; the landed tree matches the reviewed candidate (1d6e6de3f94b8c1c3dcf7b78bbbf01226302863b). The Rails-label Compiler identity and evidence were preserved.

Current schema, serializer, and existing import/fixpoint and invalid-child tests were inspected. The paragraph patch remained identical through the rebase, so the focused independent approval was retained. Pinned bin/ci docs passed 32 documentation checks and 74 guide checks on the new base; git diff --check passed. Current-head hosted CI passed every group, including test, compiler, and aggregate ci.

Earlier candidate bb70b29f on 583c1d36 passed all hosted groups except one GitProcess cleanup wall-clock assertion (1.235 seconds versus 0.5 seconds; one failure, no errors). Its failed-test retry attempt 2 was cancelled when main advanced, before a successful test result. That retry supplies no passing evidence; the later current-head run above is the successful integration gate. The assertion and implementation were not changed for this correction.

The issue remains open for the useful-list-content authoring decision, exact September 22 warning reconciliation, and richer populated narrow-screen preview. Only the documentation correction is complete. No separate local application/database qualification or new public-lifecycle proof was claimed, and no release or deployment occurred.