QORPOTAMITOS Move: points and sponsored help need separate states
TAMITOS Move’s points balance and sponsored help answer different questions. A balance records activity credit; a funded contribution needs an active sponsorship arrangement and permission to convert points. Reviewing the current development implementation shows why those states must stay separate, including what should happen to points while conversion is unavailable. This is an implementation explanation, not an announcement of a new sponsor or a promise of future money.
A useful boundary for a movement app
A person can complete an outing when there is no funded campaign available. Treating those two events as the same thing would make the interface misleading: an accepted activity could look like a donation even though no money had been allocated. The product needs language for activity, points, an available contribution and a completed contribution.
That distinction also matters beyond the screen. A family should not have to interpret an activity total as cash received. A participant should not have to guess whether a points balance is a withdrawal balance. For the public introduction, start with TAMITOS Move and its explanation that TAMI points are not euros.
What the implementation separates
The development code we reviewed keeps a point ledger, asks whether a sponsored period is active and checks whether conversion is enabled. Its tests describe refusing a conversion without deducting points when the required state is unavailable. These are implementation and test-intent observations. Reading a test does not establish that a particular mobile release passed it or that a particular participant completed a contribution.
This distinction is why a change log should avoid turning “the condition exists in code” into “every user has this today”. A public release statement needs evidence from the deployed service and the client build that actually presents the state. Our guide to production evidence explains that wider boundary.
The deadline should agree with the action
The same reviewed implementation links weekly point expiry to whether sponsored conversion can operate, with additional controls that can stop expiry. The accompanying tests cover no sponsored period, an active period and conversion being switched off. The intended result is coherent: a deadline should not urge someone to use points on an action that the product currently refuses.
That is a bounded code observation, rather than an everlasting rule for every future campaign. Participants should read the current terms and the state shown in their installed app. We are not announcing a conversion rate, expiry date or campaign opening here. Those details need their own current product evidence.
An original example: activity accepted, contribution unavailable
Consider an invented review scenario. A participant finishes a short outing and the app accepts the activity. The points balance changes, while the contribution area says that sponsored conversion is unavailable. A useful explanation acknowledges the accepted activity and explains the unavailable action separately.
In that scenario, a reviewer should ask three concrete questions. Is the updated points balance visible? Does the contribution area explain its current state? Does attempting the unavailable action leave the balance unchanged? These are proposed checks, not a report of a test session we performed.
Avoid adding an invented euro amount beside the outing to make the screen more exciting. That would erase the funding boundary the interface is meant to communicate. Equally, a direct gift should retain its own receipt and status instead of being presented as another way of spending activity points.
Follow one contribution through its states
An original acceptance exercise can begin with a written state table. Record what the participant is allowed to do before a funded period, during an eligible period and after conversion is disabled. For each state, specify the action label, explanatory sentence and effect on the point ledger. Use fictional accounts and amounts in the exercise.
Then review the same journey with interrupted connectivity and a return to the app. The goal is to establish what happened to the action, rather than infer it from a dismissing animation. A pending response, a refused action and a completed contribution need different language. Any financial test must use the project’s authorised test environment; this article performs no transfers.
A clearer studio progress report
For QORPO, this is a useful example of product work that cannot be described by counting commits. The meaningful questions concern understandable states and evidence: can someone distinguish movement from money, and can the team trace the result of an action? Neither a larger balance nor a faster animation proves beneficiary impact.
The work also connects to consistent outing totals. Accepted distance, credited points and funded support are related parts of a journey, but each needs its own meaning. Keeping that meaning clear gives users a better basis for deciding what to do next.
Common questions
Are points a promise of euros later?
No promise is made here. Funding, campaign conditions and product availability must be verified at the time of the action. A points balance alone does not establish money owed to a participant or family.
Did this article confirm a new production release?
No. It reports the implementation and test intent reviewed on 6 November 2026. It does not claim a mobile test pass, a new sponsor, a conversion transaction or an observed donation outcome.
Explore the TAMITOS world for the public product journey and follow QORPO Live for studio activity with release status kept in context.