I'm still working on it.

I'm still working on the payment retry issue. The main implementation is done, but I'm checking one edge case around duplicate callbacks. I should have an update by this afternoon. No blocker for now.

I'm working on [task].
Current status: [progress].
The main issue is [blocker/risk], or no blocker for now.
Next, I'll [next action].
I expect to [timeline / outcome].

I'm working on the login rate-limiting task.
Current status: the middleware is implemented and unit tests are passing.
The main issue is that I still need to confirm the Redis TTL behavior in staging.
Next, I'll run a staging test with concurrent login attempts.
I expect to post the result before the end of the day.

I'm working on the rate-limiting task. The implementation is mostly done, but I still need to validate the Redis TTL behavior in staging. I'll share the result later today.

The rate-limiting task is mostly done. I'm validating one Redis TTL case and will share an update later today.

I haven't started it yet because I'm still finishing the API migration task.

I haven't picked it up yet. I plan to start after lunch.

It's still in my queue. I can start it once the current blocker is resolved.

It's in progress. I'm currently working on the validation logic.

I'm in the middle of implementing the retry mechanism.

I've started it, but it's still early. I don't have a reliable estimate yet.

The main implementation is done, but the tests are not complete yet.

The backend part is done. I'm still coordinating with frontend on the error states.

The happy path works. I still need to handle a few edge cases.

The code is implemented, but I haven't tested it end to end yet.

It works locally, but I still need to verify it in staging.

The unit tests pass, but I need to add integration coverage.

I'm waiting for the API contract to be confirmed.

I'm waiting for review from the platform team.

This is currently waiting on a product decision.

I'm blocked because the staging environment is unstable.

I'm blocked on access to the production logs.

I can't move forward until we decide which migration path to use.

The PR is ready for review.

The change is ready to merge once CI passes.

The fix is deployed to staging and ready for QA.

The fix has been deployed, and I'm monitoring the error rate.

The rollout is at 10 percent. So far, the metrics look stable.

We're monitoring latency before increasing the rollout percentage.

Done → Doing → Next → Risk

I've completed...
I'm currently working on...
Next, I'll...
The main risk is...

I've completed the database migration script and tested it locally. I'm currently adding rollback handling. Next, I'll run it against staging data. The main risk is that some old records may not match the new schema.

The migration script is done locally. I'm adding rollback handling now. The main risk is old records with inconsistent schema.

I'm blocked by [specific issue].
I tried [attempted solution].
The current impact is [impact].
I need [specific help/decision/access].

I'm blocked by a permission issue in the staging database. I tried using the standard service account, but it doesn't have access to the new schema. The current impact is that I can't validate the migration script. I need temporary read access or someone from the infra team to run the validation query.

I'm blocked.

I'm blocked on staging database access. I need read access to validate the migration script.

I'm blocked on the feature flag configuration. I can implement the code, but I need confirmation on the rollout strategy before merging it.

I'm blocked because I can't reproduce the production error locally. I need access to the exact request payload or more detailed logs.

I'm blocked by a failing integration test that seems unrelated to my change. I'm checking whether it's flaky or caused by the new validation logic.

Can you help me with this?

Could you help me check the retry logic in this PR? I think the failure happens when the external API returns a timeout after the first attempt. I've checked the logs, but I'm not sure if the retry count is being applied correctly.

Could you help me [specific action]?
I'm trying to [goal].
I already checked [what you tried].
I'm not sure about [uncertainty].

Could you help me review the error handling in this service? I'm trying to make sure we don't retry non-retryable errors. I already checked the existing error mapping, but I'm not sure whether 409 should be treated as retryable in this flow.

I don't know.

I don't know yet, but I can check the logs and get back to you by this afternoon.

I'm not sure yet. My current guess is that it's related to the cache invalidation, but I need to verify it.

I don't have enough context to answer that confidently. Let me check the previous design doc first.

I don't know yet + current hypothesis / next action / follow-up time.

I don't know yet. My initial guess is that the job failed because of a timeout, but I'll verify it from the worker logs and update you in the thread.

I'm not sure yet.

I need to verify that.

I don't want to guess without checking the logs.

I can give you a better answer after I inspect the data.

My current understanding is..., but I need to confirm it.

Not yet.

Not yet. I'm still validating the edge cases.

Not yet. The implementation is done, but I still need to add tests.

Not yet. I ran into an issue with the staging environment, but I'm working around it.

Not yet. I expect to finish the first version by tomorrow morning.

Not yet + current state + next action + expected update.

Not yet. The backend change is ready, but I'm still waiting for confirmation on the frontend error message. I'll follow up with design today.

This may take longer than expected because [reason].
The current status is [status].
The impact is [impact].
My proposed next step is [plan].

This may take longer than expected because the existing data has more inconsistent records than we assumed. The migration script works for the normal case, but it fails on some legacy records. The impact is that I may need one extra day to add validation and rollback handling. My proposed next step is to split the migration into two smaller batches.

Still working on it.

This is taking longer than expected because the integration test exposes a schema mismatch. I can still finish the implementation today, but the full validation may move to tomorrow.

The token expires after 900 seconds, and then the worker retries three times, but the cache key is not updated, so it returns the old payload.

We're seeing intermittent failures in the invoice generation flow. The main issue seems to be token expiration during the worker retry. When the token expires, the worker may reuse an old cached payload.

For context, this is about [area/feature/flow].
The issue is [symptom/problem].
The relevant detail is [technical detail].

For context, this is about the checkout callback flow. The issue is that some callbacks are processed twice. The relevant detail is that the idempotency key is generated after validation, not before it.

Here's the current status.
What has been done is...
What's still missing is...
The main risk is...
The next recommended step is...
Relevant links are...

Here's the current status. The API change is implemented and tested locally. What's still missing is staging validation with real callback payloads. The main risk is duplicate processing if the idempotency key is missing. The next recommended step is to run the staging test with the sample payload from yesterday's incident. The PR and logs are linked in the ticket.

Let me give you the current context.

The latest status is...

The part that needs attention is...

The main thing to watch out for is...

If you continue from here, I suggest starting with...

Everything is documented in the ticket, but the key point is...

Let me make sure we're aligned.
We are going to [decision/action].
The scope is [scope].
The owner is [owner].
The expected timeline is [timeline].
Anything I'm missing?

Let me make sure we're aligned. We are going to ship the backend change first behind a feature flag. The scope is limited to the checkout flow, not the refund flow. I'll own the backend PR, and Nina will validate the frontend behavior. We expect to test it in staging tomorrow. Anything I'm missing?

Just to confirm, the priority is reliability over speed for this release, right?

So the decision is to delay the migration until we complete the rollback plan, correct?

Let me repeat the next step: I'll update the API contract, and you'll confirm it with mobile. Is that right?

I want to flag a potential risk.
The issue is [issue].
The impact is [impact].
The current blocker is [blocker].
I think we need [decision/help/action].

I want to flag a potential risk. The migration script works for normal records, but fails for some legacy data. The impact is that we may not be able to complete the migration safely this week. The current blocker is that we don't have a confirmed rollback path. I think we need a decision on whether to delay the migration or reduce the scope.

The infra team didn't give me access, so I can't do anything.

I'm currently blocked on database access. I requested access yesterday, but it hasn't been approved yet. The impact is that I can't validate the migration script. Could we help prioritize that approval?

I've finished the initial implementation.

I've made some progress on the API changes.

I'm still working through the edge cases.

The main logic is done, but the test coverage is still incomplete.

I have a working version locally.

I'm blocked on access to the staging database.

I'm blocked because the API contract is still unclear.

The main blocker is the failing integration test.

I need a decision before I can move forward.

I need more context on the expected behavior.

Could you take a quick look at this?

Could you sanity-check my approach?

Could we pair on this for a few minutes?

Can you help me understand why this was designed this way?

Who would be the right person to ask about this?

I'm not fully sure yet.

My current hypothesis is...

I need to verify that with the logs.

I don't want to assume without checking the data.

I'll confirm and update the thread.

Next, I'll add integration tests.

Next, I'll validate it in staging.

Next, I'll check the logs from yesterday's incident.

I'll follow up with the platform team.

I'll post the result in the ticket.

I already finish the task.

I've finished the task.

The task is done.

I've already pushed the fix, so we can start testing now.

It's still progress.

It's still in progress.

I'm still working on it.

Let's discuss about the API design.

Let's discuss the API design.

Let's talk about the API design.

Can you explain me the issue?

Can you explain the issue to me?

Can you walk me through the issue?

I confuse about this behavior.

I'm confused about this behavior.

I'm not sure I understand this behavior.

Until now still failing.

It's still failing.

It has been failing since yesterday.

I'm still doing the task. Maybe today finish.

I'm still working on the login throttling task. The implementation is mostly done, but I'm validating the behavior when Redis is unavailable. I expect to finish the validation today and open the PR tomorrow morning.

Could you give me more context on this requirement? I understand that we need to block duplicate transactions, but I'm not sure whether the rule applies only to checkout or also to refunds.

I'm blocked on the staging environment. The deployment keeps failing because the migration job times out. I checked the application logs, but I need help from infra to inspect the database lock.

Not yet. The implementation is done, but I found one edge case during testing. If the external API times out after creating the transaction, our retry logic may create a duplicate pending state. I'm fixing that now.

Just to confirm the next step: I'll update the backend validation, and Maya will update the frontend error message. We'll test the full flow in staging tomorrow. Is that correct?

10 min — Warm-up phrase reading
15 min — Status transformation drill
15 min — Blocker explanation drill
10 min — Help request roleplay
10 min — Recording and correction

Still working.

I'm still working on the notification retry task. The main logic is done, but I'm adding tests for timeout handling. No blocker for now.

Not yet.

Not yet. The implementation is complete, but I still need to validate it in staging. I'll update the ticket once the staging test passes.

Blocked.

I'm blocked on access to the production-like dataset. I need it to validate the migration script against legacy records.

I'm blocked by...
I tried...
The impact is...
I need...

Could you help me...?
I'm trying to...
I already checked...
I'm not sure about...

## Daily Work Phrasebank

### My Common Tasks
- I'm working on...
- I'm validating...
- I'm debugging...
- I'm refactoring...
- I'm reviewing...

### My Common Blockers
- I'm blocked on...
- I need clarification on...
- I need access to...
- I need a decision on...

### My Common Next Steps
- Next, I'll...
- I'll follow up with...
- I'll post an update in...
- I'll validate this in...

Current task → Current status → Blocker/risk → Next step → Expected update