Sale Manager Settings Now Mean What They Say

There is a particular kind of bug that is worse than a crash. The app works — it just silently does the opposite of what you told it to do.

That is what we found in Sale Manager's settings layer. Four controls were wired up in the UI and documented in the settings screen, but the runtime underneath them either ignored what they said or implemented something different. If you set a lever to "off," it still behaved like "suggest." If you turned the master switch off, evaluations kept running. If you enabled auto-enroll on publish, nothing happened. And there was a daily budget field whose value was checked but never actually decremented by anything, making its enforcement meaningless.

This release closes all four of those gaps. Here is what changed, why it matters, and what you can now rely on.

The Four Problems, Fixed

Posture "Off" Now Actually Turns the Lever Off

Sale Manager has a posture setting for each automation lever: suggest, auto, or off. The intent is clear: "suggest" means the AI proposes changes and you approve them; "auto" means it acts without review; "off" means that lever does nothing.

Except "off" was not doing nothing. It was behaving exactly like "suggest." Setting price posture to off would still generate price proposals in your review queue. Setting visibility posture to off would still queue visibility recommendations. The off setting was functionally identical to suggest, which made the whole posture system misleading.

The fix is precise: when a lever's posture is set to "off," any proposals from that lever are now stripped before they reach your queue, and replaced with an explained hold note. You will see something like: "the visibility lever is off in your settings, so this proposal was withheld." That message is logged in the evaluation record so you have a clear audit trail. The proposal never surfaces for approval, and the AI never acts on it.

Before vs. After:

The off and suggest postures now behave differently, as they were always supposed to.

The Master Switch Actually Pauses Evaluations

Sale Manager has an organization-level master switch: Enabled. When you flip it off, the intent is that Sale Manager stops doing anything for your account.

That was not what was happening. The scheduled evaluation runner did not check the master switch. It would keep picking up enrolled listings and queuing evaluation jobs regardless of whether you had disabled Sale Manager at the org level. The only way to fully stop activity was to unenroll everything manually.

Now the evaluation scheduler checks the master switch before running. If enabled is set to false in your organization settings, the scheduler skips the run entirely. Enrollments are left exactly where they are, with their nextEvaluationAt values untouched, so when you re-enable Sale Manager, everything resumes from where it paused. There is no re-enrollment step, no loss of state.

One edge case handled intentionally: if an account has no Sale Manager settings saved yet (a fresh account, or one from before this feature existed), the system fails open. Pre-existing enrollments are not frozen just because settings were never explicitly saved. The absence of a setting is treated as "enabled" to avoid locking users out on deploy.

Auto-Enroll on Publish Works End-to-End

Auto-enroll on publish is the setting that automatically puts a listing into Sale Manager the moment you publish it. It is a quality-of-life feature for sellers who want every new listing managed from day one without manually enrolling each one.

This setting existed in the UI and in the settings contract, but nothing in the backend was listening to it. Publishing a listing did not trigger any enrollment logic. The setting was inert.

The implementation is now wired up. When a listing transitions to "published," the system evaluates whether it should be auto-enrolled using a clean, pure function that resolves the enrollment decision in priority order:

1. If the listing has an explicit enrollmentOverride of never, it is never enrolled regardless of org settings.
2. If the listing has an explicit enrollmentOverride of always, it is enrolled even if the org's auto-enroll is off.
3. Otherwise, the org's autoEnrollOnPublish setting applies, but only if the master switch is also on. A disabled Sale Manager does not quietly accumulate enrollments behind your back.

The enrollment call itself is the same idempotent enroll() function used everywhere else. If the listing is already enrolled, nothing changes. If it needs research before a sale window can be proposed, it parks in a pending research state. If the listing has already hit a terminal state in its lifecycle, the auto-enroll is skipped.

The Phantom Daily Budget Field Is Gone

Sale Manager's visibility band had a field called dailyBudgetRemaining. The intent was to let you cap how much the AI could spend on promoted listings per day, with the guardrail refusing further promotion actions once the budget was exhausted.

The problem: nothing ever decremented dailyBudgetRemaining. The field was checked in the guardrail, but the value never actually went down after a promotion action. The only thing this field could ever do was block promotions if you manually set it to zero. It was a budget guard with no budget tracking behind it.

Rather than build the accounting layer that was never built, we removed the field entirely. It is gone from the type definitions, the settings contract, the guardrail, the LLM prompt, and the mobile settings screen. The visibility band now only exposes maxAdRatePercent, which is the constraint we can actually enforce correctly.

If you were relying on dailyBudgetRemaining as a zero-value stop, the correct control going forward is the posture setting: set visibility posture to "off" to fully prevent the AI from touching promoted listings.

What This Means in Practice

If you have been using Sale Manager and noticed that turning things off did not seem to change behavior, that was a real problem and it is now fixed. Here is how your existing setup is affected:

Posture settings: Any lever you had set to "off" will now actually suppress proposals from that lever. You may notice fewer items in your review queue after this update. That is expected and correct.

Master switch: If you have Sale Manager disabled at the org level, evaluations are now fully paused. Re-enabling it will resume from the current state.

Auto-enroll on publish: If this setting was on, it now does what it says. New listings you publish will be enrolled in Sale Manager automatically.

Daily budget remaining: If you had a value set for dailyBudgetRemaining, that field no longer exists. Your visibility band now only has the ad rate cap. No action needed on your part, but be aware the field is gone.

Why Getting This Right Matters

Sale Manager is making decisions about your listings. It is proposing price changes, recommending visibility adjustments, and acting autonomously when you let it. The entire value of having a settings layer is that you can control where it operates and where it does not.

When settings do not do what they say, the system becomes untrustworthy in a specific way: you cannot reason about what is happening. You think you turned something off. You did not. You think auto-enrollment is happening. It is not. You think the master switch stopped activity. It kept running.

These are not cosmetic bugs. They erode confidence in the controls you use to manage risk. Fixing them is not a feature addition; it is making the product honest about what it does.

We caught these gaps through an internal audit of the settings layer, cross-referencing the UI controls with the actual runtime behavior. Tim reviewed each one and confirmed the intended behavior before we changed anything. The fixes were deliberate and targeted.

What Is Next

The visibility lever posture is still in a "ships in a later phase" state for the autonomous path. You can set visibility proposals to suggest or off, but auto mode for visibility is not yet live. That is by design: visibility changes (promoted listings, ad rate adjustments) have spending implications and we want to get the guardrails right before enabling autonomous execution there.

Budget tracking for daily promotion spend is also on the roadmap. When it arrives, it will be built with proper accounting rather than the static field that was there before.

Sale Manager is in active development and getting more capable with each release. If you are not using it yet, list-forge.ai is the place to start.