[1.0 T7] Make Product and Constitution the human view of direction and principles #183

Problem and outcome

Help people understand and challenge product direction and principles without requiring a complete brief or turning the local site into a compliance dashboard.

Interaction contract

Keep FluencyLoop. Proposed positioning: Stay fluent as people and agents evolve the product.

Use retained product reasoning automatically. Explain consequential choices at the right depth. Recommend a path. Continue within agreed intent. Ask when human judgment is needed. Update the shared model at natural boundaries.

The flagship goal/principles/precedents/tradeoffs reasoning is integrated into the existing design explanation at proportional depth. It is not a mandatory recital, proposal form, or new approval exchange. People must remain able to understand and challenge the design.

Scope

• Show expressed/agreed direction separately from implemented behavior. Read an optional brief distilled from intent; absence is a useful empty state, not failed onboarding.
• Explain principles with rationale, representative applications, and navigable tensions. Distinguish delegated decisions, confirmed human choices, and evidence trust as provenance rather than approval badges.
• Expose stale-support and missing-record information on inspection without recurring nags, completeness scores, or mandatory knowledge-repair tasks.
• Review real-content prototypes before wider view work. Keep the site optional to open, local, accessible, and based on existing visual tokens.

Acceptance criteria

• A person can distinguish direction/current behavior and locate the reason behind a principle.
• A project without a brief remains useful and has no blocked onboarding state.
• The site supports understanding and challenge rather than measuring record completeness or approval count.
• Unknown/stale states are visible but do not demand repair to continue implementation.
• Populated and sparse views remain readable and keyboard accessible at desktop/narrow widths.

Validation

Use populated, absent-brief, sparse, stale-support, and conflict fixtures plus targeted browser checks. Observe a person locating and questioning a principle application without the original chat.

Starting points

plugins/fluencyloop/site/server.js renderProduct/renderConstitution; site.css, site.js; tests/site.bats and PowerShell mirror

Constraints

• Target dev; main distributes releases. No runtime implementation occurs in the planning PR.
• T1 is an observed pilot using existing artifacts before new infrastructure. Use its evidence to retain, narrow, or defer later scope.
• Recommend and continue within authorized intent; ask with a recommendation only for consequential unresolved judgment. Batch independent questions, reuse settled answers, and wait for dependent work. Silence is not approval.
• Absent briefs, historical link gaps, stale prose, and unreviewed metadata alone are advisory. Do not require onboarding, cleanup, or retrospective approvals to work.
• Unknown familiarity is not fluency and does not automatically require a blocking probe/check. Support requested guided learning without quizzes; keep calibration/preferences private. T5 explicitly updates inherited pause rules.
• Capture rationale once, link mechanical views, record outcome deviations at natural closure, distill once at wrap-up, and reuse unchanged context.
• Preserve append-only history/provenance; Bash and PowerShell implement the same contract. Core remains Node-optional; no new database, hosted service, or vector search.

Dependencies and size

• Task: T7
• Relative size: M (not a calendar estimate)
• Depends on: T1: [1.0 T1] Pilot recommendation-first design and define the flow contract #177, T2: [1.0 T2] Add stable record references and explicit decision lifecycle #178
• Milestone: https://github.com/baokhang83/fluencyloop/milestone/3
• Plan: draft source
• Planning PR: docs: propose FluencyLoop 1.0 shared product direction and design #189