Flower MCP 0.8.1

Flower MCP 0.8.1

Flower's bootstrap, discovery recipe and persistent project AGENTS template now
explicitly require the coding agent to question factual and technical premises,
including its own preferred solution, seek counterevidence and revise conclusions
when evidence contradicts them.

Known deviations, omissions and substitutions must be disclosed before approval
of the proposal or affected execution, with the original obligation, difference,
reason, behavioral consequences, affected criteria and evidence or uncertainty.
Stakeholder intent stays authoritative; technical choices within that intent
remain the engineer's responsibility. Existing reassessment and scope-confirmation
rules apply. No extra approval after every unit or compulsory opposition/testing
is introduced. See the bootstrap guide.

Upgrade

Use the ordinary same-profile upgrade.
Keep the existing environment, database, profile, YAML and client configuration.
Stop the owner; the unchanged --upgrade path creates its consistent SQLite/YAML
backup before pip. SQLite remains schema55 with no new migration, dependency or
server contract. Keep the backup; failed pip is not an atomic rollback.

Project AGENTS files are not edited by the package installer. Print the new
bootstrap and merge the new subsection into the existing Flower marker while
preserving project locators and custom rules. Earlier releases remain immutable.

Qualification boundary

The completed semantic review, focused exposure tests and exact resource/package
checks are reused. The Release workflow qualifies this versioned artifact before
publication. Instruction exposure is not proof of model adherence, reduced
sycophancy or stakeholder usability. No provider/model, witness or native client
acceptance is implied.

Flower MCP 0.8.0

Flower MCP 0.8.0

Flower can now register directly with OpenCode V2 through the Python, Bash
and PowerShell installers. Select opencode, or run the installed
flower-mcp install --platform opencode command for an existing profile.

The adapter generates OpenCode's mcp.servers structure with an absolute Python
command array and codemode: false, keeping Flower's direct engineering verbs
available to the host. It reuses ownership receipts, pure dry-run and replay,
explicit replacement/backups and owned removal. Configuration and receipt
comparisons preserve JSON types, so numeric zero cannot impersonate a boolean.

The default follows OPENCODE_CONFIG_DIR, then XDG_CONFIG_HOME/opencode, then
~/.config/opencode; an explicit --client-config selects another file.
Existing JSONC siblings and V1 server layouts produce actionable diagnostics
rather than a silent conversion or competing configuration. See the
OpenCode guide for manual JSONC/HTTP setup and project AGENTS
bootstrap. Existing project rules, provider settings and client approvals remain
under their owners' control.

Upgrade

Use the ordinary same-profile upgrade.
SQLite remains schema55; dependencies and upgrade algorithms are unchanged.
Keep the same environment, database, profile, YAML and client paths. Stop the
owner, preview with --upgrade --dry-run, then apply the existing backup-before-
pip upgrade and restart that profile. Keep the backup; failed pip is not an
atomic rollback. Register OpenCode separately after the package upgrade.

No migration, database reset, pending work execution or historical replay is
required. Earlier releases and their assets remain immutable.

Qualification boundaries

Focused source and installed MCP workflows, generated stdio startup/restart and
an isolated OpenCode2.2.5 connection on macOS arm64 were verified. A cold
one-shot mcp list can precede asynchronous plugin activation; inspect a ready
session when checking the connection. This does not certify native model tool
use or native OpenCode execution on Windows/Linux. Release CI qualifies its own
declared installer/package/platform surfaces; it does not imply those additional
acceptances. Provider/model integrations and paused witness work are unchanged.

Flower MCP 0.7.6

Flower MCP 0.7.6

A replacement plan can now include answers to the construction questions that
were valid before replacement. Flower records the complete batch and plan in one
transaction, preserving original question identities, submitted answers and
explicit retained/reopened/ceased-applicable outcomes. A future-only new-file
plan no longer deletes a valid question before recording its supplied answer.

New command receipts cover plan, answers, actor, scope and declared revision
conditions. Exact replays remain historical and cannot answer newly introduced
gates or queue provider work again. Changed replays conflict. Historical plan-only
receipts cannot verify supplied answer batches and fail explicitly rather than
silently discarding, remapping or replaying them.

The existing packet history read exposes immutable completion receipts with
provenance and revisions after later plans. Replace-plan and question-batch errors
return structured diagnostics and multiline Markdown, with scoped read-only
recovery guidance. Effects remain unknown where no pre-write proof exists;
rollback is not a global no-effect receipt. See plan authoring.

Upgrade

Use the ordinary same-profile upgrade.
SQLite remains schema55. Keep the same database, profile, YAML and client paths;
stop the owner, preview with --upgrade --dry-run, then upgrade with the existing
backup-before-pip installer and restart that profile. Dependencies and installer
algorithms are unchanged. Existing data and unknown historical calls are not
rewritten or replayed. A failed pip install is not an atomic rollback.

The optional runtime/provider configuration, actual project acceptance and paused
witness work are unchanged. This release neither executes repository work nor
automatically recovers an old host operation.

Flower MCP 0.7.5

Flower MCP 0.7.5

Recorded milestone risk treatment no longer manufactures a human approval gate.
The existing review_milestone_risk action remains visible with its identity and
priority, but is an orchestration advisory linked to a scoped traceability read.
Snapshots classify it as intent_work, with advisory: true and
establishes_global_admission: false, rather than acceptance/open decisions.
Original risk prose is retained; no text matching infers consent or accepted risk.

Snapshots explain that secondary actions are ordered options or context, not
conjunctive admission prerequisites. Repository review Markdown explains that
human_acceptance: false means non-attestation, not a new approval requirement
before each subsequent confirmed milestone. Full requested review coverage and
original structured flags remain intact. Recipe, help, offline plans and shipped
bootstrap repeat the distinction. See engineering cycle.

Actual entry/dependency/PVP/semantic/roadmap predicates and explicit
entry_policy.requires_milestone eligibility are unchanged. Genuine risk exceptions,
finding/campaign decisions and human acceptance still require their ordinary
authority/evidence. Nothing accepts a milestone or resumes a real project on update.

Upgrade

Use the ordinary same-profile upgrade.
Keep the existing SQLite database, YAML, client configuration and environment.
Schema55, dependencies and installer algorithm are unchanged; the existing installer
backs up before pip and rejects active ownership. No migration or reset is needed.

Verification boundary

Focused regressions and source/installed public MCP qualify narrative advisory,
scoped routes, unchanged entry eligibility, non-attestation/full review presentation,
read-only SQLite state and both response channels. Independent severe review and
existing exact-commit Release CI gate publication. Private baseline fixture failures
remain recorded separately, without weakening tests or claiming they passed.
Native preview adoption belongs to its owner. No benchmark acceptance, model quality,
new runtime, U6 or product acceptance is inferred.

Flower MCP 0.7.4

Flower MCP 0.7.4

Validation and blocked TODO now show the overall execution decision separately
from PVP preparation, first observed admission and the semantic findings subgate.
A roadmap confirmation hold no longer hides the available PVP repair guidance.
Primary status, reason, next gate, raw PVP and all admission guards are unchanged.

A focused diagnostic preserves both original local-check strings and explains
exact same-unit verification correspondence. expected_count counts distinct
candidate declarations, never tests run or passed. Flower supplies no automatic
criterion mapping, patch, waiver or evidence. Standard/full responses preserve
both Markdown and structured channels. See plan authoring.

Exact help clarifies that the coding agent can record actual applicable roadmap
consent/delegation through the canonical operation and current fingerprint/reference.
No native UI is mandatory and no consent is inferred. Noxi's native route, lens,
context recovery and preview remain separately owned consumer behavior.

Upgrade

Follow the ordinary upgrade in the existing
environment/profile. Retain the same SQLite database, YAML and client configuration.
The unchanged installer backs up before pip and rejects an active owner. Schema55,
dependencies and installer algorithm are unchanged; no migration or reset is needed.

Verification boundary

Focused source regressions and independent severe review qualify preserved gates,
exact strings/counts, unchanged PVP/fingerprints and read-only SQLite state. Source
and installed public MCP checks use dedicated model-disabled state and exercise
simultaneous roadmap/PVP blocks plus ordinary repair and closed PVP still held by
roadmap admission. Existing Release CI gates the exact final public commit.
No benchmark execution, real consent, model usability, U6, product acceptance or
root-managed client upgrade is implied. Native adoption belongs to its owner.

Flower MCP 0.7.3

Flower MCP 0.7.3

An open PVP now clearly holds affected repository execution while engineering
investigation and ordinary plan preparation continue within confirmed intent.
The recipe and exported Markdown explain how to complete ownership, verification
intent and producer/consumer declarations. A draft remains nonexecutable;
new gaps found offline are retained as observations/proposals for ordinary
accepted mutations on reconnection. No PVP or human approval gate is waived.

Exact replace_plan and revise_unit help includes concrete examples and the
relationship among implements, unit_checks and verifies. A local check needs
an exact same-unit kind=unit_check verification statement; criterion prose is
separate; selecting which active criterion a check verifies requires engineering
investigation. Stable criterion numbers are unchanged. Array patches replace whole
arrays. Use current returned revisions, review/accept the new proposed plan and
revalidate before execution.

Read-only validation/TODO responses add a bounded next_gate.repair descriptor
for known declaration gaps, preserving the original PVP and primary read route.
It names current known identities, CAS and exact authoring help, but remains
ready_to_call=false with no generated patch, criterion mapping, actor or request.
Ambiguous producer/consumer repairs remain explicit engineering choices.
See plan authoring.

revise_unit failures now use the existing structured mutation guard and retain
original request correlation. Ancillary lifecycle repair may already have run:
failed mutation effects remain unknown, without a fabricated no-effect receipt.
A blocked PVP read remains an observation. Updating code never replays work or
rewrites uncertain historical responses.

Upgrade

Use the ordinary upgrade with the same
environment, profile, SQLite database, YAML and client configuration. The installer
backs up SQLite/YAML before pip and rejects active owners. Schema 55, dependencies
and installer behavior are unchanged. No data migration or project reset is needed.

Verification boundary

Focused deterministic regressions, independent severe review and source/installed
public MCP checks cover incomplete plans, read-only hints, strict draft export,
explicit targeted repair, proposed-plan acceptance and stale CAS errors. Existing
Release CI gates exact packages. Real client adoption belongs to its owner;
no new upgrade campaign, model benchmark result, U6 or human acceptance is claimed.

Flower MCP 0.7.2

Flower MCP 0.7.2

Packet architecture references now expose their exact nested shape:
revision, kind and entity_id. Malformed references are rejected with a
correlated no-mutation proof before packet lifecycle repair can start. Omitted
references retain their meaning; an empty list clears them. Errors after repair
or dispatch remain uncertain and never erase earlier effects.

Read-only external-work views preserve roadmap confirmation gates without
misreporting them as uncertain mutations. Unexpected read failures have a bounded
read diagnostic and exact-operation guidance. No gate is bypassed.

A separate packet revision recovery guide and
source-archive assessor support owner investigation of the retained malformed
0.7.1 revision. The requested revision was not dispatched on that supported path,
but earlier lifecycle repair may have written maintenance state. A strictly joined
readiness record can attest that maintenance occurred; it never proves complete
attribution or invocation-wide absence of effects. The original unknown response
is retained. Client reconciliation remains an explicit owner action.

Upgrade

Use the ordinary upgrade, retaining the
existing environment, profile, SQLite database, YAML and client configuration.
The installer backs up SQLite and YAML before pip and rejects active owners.
Schema 55, dependencies and installer behavior are unchanged; no data migration
or project reset is needed. Updating code does not replay or recover an uncertain
historical operation automatically.

Verification boundary

Focused schema, preflight, prior-effect, read-gate and historical-assessment
regressions, independent severe review and public MCP verification cover the
changed source and installed surface. Release CI gates the exact packages.
Historical fixture mechanics and native owner reconciliation remain distinct;
no new upgrade campaign, model usability, witness U6 or human acceptance is claimed.

Flower MCP 0.7.1

Flower MCP 0.7.1

Architecture proposals/adoptions rejected during pure structural validation now
carry an explicit, correlated proof that the invocation started no mutation.
The diagnostic names the invalid field and links its exact operation contract.
Errors during/after dispatch, rollback and lost responses remain uncertain;
a rejection never erases earlier effects under the same request identity.

A separate source-archive utility supports read-only owner assessment of the
retained0.7.0 malformed-boundaries proposal. It pins original artifact/input bytes,
requires explicit owner association and corroborating SQLite reads, preserves the
original unknown response, and never replays the failed or corrected proposal.
See architecture recovery.

Upgrade

Use the ordinary upgrade. Keep the existing
environment, profile, SQLite database, YAML and client configuration; the existing
installer creates a consistent backup before changing packages and rejects active
owners. SQLite remains schema55; no migration, dependency change or installer
behavior change is introduced. Installation does not itself recover an uncertain
client request. Older releases, evidence and human acceptance remain separate.

Verification boundary

Focused rejection/replay/conflict/rollback tests, independent severe review and
public MCP checks cover the changed source and installed surface. Existing
release CI gates the exact packages; no new broad lifecycle or upgrade campaign
is claimed. Native client recovery/adoption belongs to its owner.

Flower MCP 0.7.0

Flower MCP 0.7.0

Flower makes canonical architecture and bounded repository reconciliation part
of the standalone engineering cycle. Coding agents continue to investigate,
implement and test with their own tools. No internal model or coding provider
is needed for these capabilities.

What changes

• New plan acceptance requires an adopted nonempty architecture and valid packet
  references. Its immutable acceptance event records engineering-cycle version 1.
• External-agent cycle-1 work records unit outcomes normally, then requires a
  current scoped repository review before final closure or dependent admission.
  Implementation, local verification, reconciliation and human acceptance remain
  distinct. Previously issued plans retain their historical contract.
• fow_audit_phase accepts an optional bounded host-declared repository review.
  It uses existing audit/events/jobs, exact request replay, conflict detection,
  source provenance and revision-bound currentness. Original committed audits
  remain recoverable independently of the latest current comparison.
• Full external validation exposes original report history, including outside
  execution admission, without promoting old evidence or relaxing execution guards.
• Host intention-grounding preparation supports an explicit requirement scope;
  omission and an explicit empty selection remain distinct. Actual truncation
  and host-declared scope limitations remain visible.
• Recipes, current gates, Markdown, structured data, offline plan exports and
  the bundled engineering bootstrap describe the same cycle. Default views stay
  compact; full detail remains explicit.

Read the engineering cycle, bootstrap and
continuous recovery for the practical workflow.
The public catalog remains 37 tools and 183 operation routes; the two additive
optional fields bring the flat input-property inventory to 447. A host's explicit
lens determines the smaller surface actually presented to its model.

Upgrade while preserving SQLite

SQLite remains at schema 55. There is no new migration, dependency change or
change to the existing ownership/backup implementation. Follow the
same-profile upgrade guide. Keep the original environment,
profile, ledger, YAML, imports/logs and coding-client configuration. Preview with
--upgrade --dry-run; stop all owners before the actual upgrade. The installer
refuses active ownership and makes a consistent SQLite backup plus an exact YAML
copy before pip. Keep the backup. Failed pip does not promise automatic restore
or atomic rollback. Restart the intended client using the same profile.

Package installation does not automatically edit existing project AGENTS.md.
Run the updated bootstrap command and authorize the host to merge its marked
section, preserving other project instructions. Existing accepted plans, outcomes,
receipts, artifacts, evidence and handovers are not rewritten by the update.

Qualification boundaries

Deterministic tests, actual public MCP workflows from source and a core-only
installed package, offline host execution/restart and independent review qualify
the bounded implementation. Release CI checks the exact published commit and
installed packages across its existing platform matrix. Official asset and
same-schema upgrade receipts are recorded separately after publication.
These checks do not assert unrestricted local-model adherence, novice usability,
human acceptance or CodingCastle/witness qualification. Witness U6 remains deferred.

Flower MCP 0.6.5

Flower MCP 0.6.5

Guided bootstrap now returns an operational continuation instead of repeatedly
rendering complete answers and cumulative audit payloads. Ordinary guided
start/state/resume/answer/correspondence/confirmation/contradiction/continuation/
completion/cancellation responses show counts, the changed answer identity and
revision, the first blocker and the existing next-gate template.

Complete authority remains accessible

Structured result.bootstrap is preserved. The additive
result.operational_projection uses flow.guided-bootstrap-operational.v1.
state_details explicitly returns full state and the recent ten-event audit
window; guidance and self-contained roadmap references remain complete.
Default operational Markdown is bounded for normal identities; unusually large
legacy actor values preserve exact detail calls and are an explicit limit.
A gate template still requires real inputs, current authority and prerequisites.
No new engineering gate, automatic questioning, coding or acceptance is added.

Constructive diagnostics and exact help

Empty, malformed or duplicate roadmap milestone selections are rejected by a
pure validator before dispatch. The correlated flow.operation-effect.v1
receipt declares rejected/none and points to the milestone-planning recipe.
Roadmap does not create milestones. This proof covers that invocation's
selection validation only; service/output/transport failures and uncertain
mutations remain conservative. Never replay an uncertain historical request
just to obtain a new receipt.

Exact bootstrap operation help now separates workflow applicability from the
general multiplexer catalog. Guided engineering does not require code-import
behavior derivation or an internal model. Progress diagnostic codes remain
visible as the operational blocker's reason.

Updating safely

Use the same-profile upgrade, retaining the
existing environment, ledger, YAML and client configuration. The unchanged
installer offers --upgrade --dry-run --backup-root, refuses active owners and
backs up SQLite/YAML before pip. Schema55, dependencies and optional
runtime-llama 0.5.0 are unchanged. 37 tools / 445 input fields remain; one explicit
read route brings the operation catalog to 183 routes. Old tags/assets stay fixed.

Qualification boundaries

Focused deterministic regressions and actual isolated public source/core-wheel
workflows verify both response channels, ten long answers, explicit details,
replay/read/rejection invariance, canonical authoring and roadmap confirmation,
restart and no internal model dependency. Severe review found and corrected the
progress-code blocker seam; only that affected seam was retested afterward.
Exact Release CI separately qualifies the official package/platform/container
and upgrade mechanics. Noxi owns actual adapter/preview qualification and
preservation; that evidence and human acceptance remain separate. Witness/U6
and paused pipelines are outside this correction.