At the bell, the main loop did exactly what it was designed to do: it ended the session. The resting profit-taking order remained open, the time stop never had a chance to fire, and the option expired worthless.

No single component was obviously broken.

The bug lived between correct components

The time stop was calculated correctly from the fill. The session loop stopped correctly at the market close. The exit order was placed correctly and waited for a price the market never reached.

The failure existed in the composition:

• the deadline code did not know when the process would stop listening
• the session-close code did not know a position still needed management
• the summary counted only journaled closes, so it omitted the abandoned trade

This is the kind of incident unit tests can miss when each function’s local contract is correct. The system-level contract—never end while a position may still be open—was not encoded.

Reuse the safety behavior already present

The frustrating part was that the bot already knew how to handle this condition.

Its emergency-halt path checked for an active position, attempted to flatten it, refused to end until the close was confirmed, and raised an urgent alert when confirmation failed. That reviewed behavior sat near an unconditional session-close branch that simply called break.

The fix reused the existing close primitive instead of adding another order path. Session end and emergency halt now share the same invariant: do not declare the session finished while the broker may still hold the position.

Derive the entry cutoff

A fixed “no new trades after this clock time” rule would solve only the current configuration. Different hold periods need different cutoffs, and shortened sessions move the close.

The entry gate is derived instead:

session_exit_deadline = market_close - operational_buffer

accept entry only if:
expected_fill_time + configured_hold_period <= session_exit_deadline

The gate uses the expected fill, not the signal timestamp. A completed signal bar can lag wall-clock time, and a submitted order can take time to confirm. The exit timer begins from the fill, so the admission decision must reason about that same clock.

The calculation also uses the session calendar, which means the cutoff moves automatically on early-close days.

Prevention and containment are different

The entry gate prevents this specific late trade. It does not cover every way a position can become stranded.

A separate authentication incident had already produced the same dangerous state through a different path. That changed the scope of the fix:

• the derived gate prevents an exit deadline beyond the session
• an end-of-session sweep contains any open position, regardless of cause
• failure to confirm the sweep keeps the recovery path alive and the alerts active

The clever rule handles one cause. The boring sweep handles the category.

An independent review found that my first retry still had a hole: it returned early while the time stop was in the future, which was precisely the original scenario. A second review corrected my explanation of broker behavior and exposed the real issue—the fallback close could not proceed until the resting exit was cancelled.

The check I am keeping is simple: whenever code computes a deadline, ask whether the program will still be alive to observe it.

Timers assume someone is around to hear them. Mine was not.

This incident review is educational and is not investment advice.

The order had filled. The bot was no longer managing the position. No time-based exit, no profit target, no recovery loop. The option later expired worthless.

My first theory was wrong in a useful way.

The retry existed, but the error never reached it

I suspected that entry confirmation was missing the authentication recovery used elsewhere in the bot.

The polling loop did call the retry wrapper. One layer below it, however, the broker method caught every exception and returned a polite success=False object. The underlying 401 Unauthorized never propagated to the code designed to refresh credentials.

The retry wrapper was not bypassed. It was starved.

The polling loop then discarded the error detail it did receive. The logs repeated “failed to fetch order” while the actual status code sat unused in the response object.

This is the danger of broad exception handling in a lower layer: it can make a function look resilient while disabling the recovery policy above it.

Shared authentication made failures routine

Multiple bot processes shared token state. When one process refreshed, another could keep an older access token in memory while its local expiry timestamp still looked valid.

The next broker call would fail, trigger another refresh, and rotate the token again. The logs showed a cascade across processes.

Instead of assuming those bursts could be eliminated immediately, I changed the system to survive them.

Unknown is a position state

The entry path now distinguishes three outcomes:

• filled — adopt and manage the position
• dead — confirmed cancelled or rejected with no fill
• unknown — neither state is proved

Unknown no longer means abort. The bot recovers authentication, checks the order again, cancels any remaining open quantity, and queries the broker’s actual positions.

If the contract is held, the bot adopts the broker quantity and begins normal exit management. If state is still ambiguous, it keeps reconciling and alerting through the session instead of returning to signal scanning.

Authentication recovery also moved to the broker layer, where every request passes through one policy. On a 401, a process first adopts the newer token already written by a sibling. It creates a new token only if adoption fails.

Review the fix in a different mental model

The sharpest review finding was a partial fill. My first “dead order” branch treated a cancelled order as flat without checking whether some quantity had filled before cancellation.

The review also caught two related mistakes:

• adopted size came from configuration instead of the position actually held
• stacked retry layers multiplied the refresh behavior I was trying to contain

Those bugs were inside the recovery code because I was still thinking in the all-filled-or-not-filled shape of the original incident.

As an independent tripwire, the bot now periodically compares its tracked positions with the broker’s positions and alerts on drift. It is intentionally alert-only. Reconciliation detects disagreement; it does not improvise a trade.

The operational lesson

An urgent notification is not risk management. I received the original alert and read it too late. Anything the system must do—such as continue managing a possibly live position—belongs in the system’s recovery behavior, not in a request for a human to notice.

The absence of fill confirmation is not evidence that no fill occurred. When the order state is unclear, ask the broker what the account actually owns and keep watching until the ambiguity is resolved.

This incident review is educational and is not investment advice.

The obvious controls are unsafe or ineffective. Changing an environment variable does not mutate the environment of a running process. Killing the process can orphan an open position with no code left to manage its exit.

The requirement was sharper: a running bot needed to observe a remote instruction, stop taking risk, and never abandon a position.

Poll a control the process can see

The bot already has a loop, so each iteration can read external state. The first version used a local sentinel file:

def is_trading_halted(*scopes):
    if halt_file_exists():
        return True
    return any(scoped_halt_exists(scope) for scope in scopes if scope)

The local file has one excellent property: it works without a network. It is the offline emergency brake. Its weakness is reachability—I still need shell access to create it.

For remote control, I added small JSON policy documents in S3. The bot makes outbound reads; my phone can update the document through a separately permissioned path. The trading machine does not expose a new web server or inbound port.

A halt is one field in a policy

A boolean would solve today’s problem and force a new format for tomorrow’s. I used a document whose fields are optional:

{
  "halt": true,
  "direction_filter": null
}

The current safety action is halt. Other fields can constrain future entries, but no remote field is allowed to increase configured risk.

Policies can exist at global, strategy, and instance scopes:

control/policy.json
control/policy.<strategy>.json
control/policy.<instance-label>.json

Ordinary fields merge from broad to specific. halt is different: it is OR-ed across every layer. A narrower document cannot undo a global halt. To resume, every active halt must be cleared.

That asymmetry is deliberate. Safety-critical state should ratchet toward less activity, not be relaxed accidentally by a more specific override.

Remote input is untrusted input

A policy edited from a phone is easy to mistype. The resolver therefore:

• accepts only known fields
• validates values before constructing the policy
• ignores an invalid document rather than applying half of it
• preserves the bot’s configured risk limits
• catches its own failures so it cannot crash the trading loop

Remote reads are cached for a short interval. The local file is checked on every iteration so the offline brake remains immediate.

Fetch failure and “no policy exists” are separate states. Repeated remote failures raise an alert because the control path may be unavailable, but they do not invent a new policy.

Halt means flatten, then confirm

My first version stopped new entries and allowed an open trade to reach its normal exit. That is a pause button, not an emergency stop.

The current behavior attempts to cancel the resting exit and market-close the position. The session ends only after the broker confirms the account is flat.

If the close cannot be confirmed, the bot does not simply exit. It continues managing the existing order path and raises urgent alerts. “I sent a close request” and “the position is closed” are different states.

Other policy changes affect future entries only. A direction filter should not mutate the terms of a trade already in progress.

The S3 missing-object trap

The least-obvious failure came from IAM. With object-read permission but no bucket-list permission, S3 can return 403 AccessDenied for a missing key rather than 404 Not Found.

A missing scoped policy is normal. A 403 looks like a broken control channel and triggers false alarms.

The fix was to grant narrowly scoped bucket-list access for the control prefix in addition to object reads. Least privilege is still the goal, but the smallest-looking permission set is not correct if it changes normal absence into an error.

The final design has two brakes: a network-independent local halt and an outbound-only remote policy. Both share one invariant: the bot may stop only after it knows what happened to the position.

This is an educational systems-design example, not investment advice.

My backtester already assigned a deterministic ID to every full configuration. Same inputs, same ID; change an input, get a different ID. Output files and crash-resume checkpoints were keyed to it.

That solved accidental overwrites. It also hid a modeling mistake: I was treating a strategy and one evaluation of that strategy as the same object.

The window changed the identity of the edge

The fingerprint included everything, including the start and end dates. When I reran a promoted configuration on newer data, it received an unrelated ID. There was no durable link saying, “this is the same strategy definition measured in a different period.”

The comparison I cared about most was the one the data model could not express.

So I split one identity into two:

• A variant is the strategy definition: entry logic and exit configuration.
• A run is one evaluation of that variant, including its data window, account-sizing assumption, and fill model.

Re-evaluating the same edge on a new period keeps the variant ID and receives a new run ID.

Partition the configuration once

The implementation starts with one canonical payload. Context keys are excluded only when producing the variant fingerprint:

_CONTEXT_KEYS = frozenset({
    "file_path",
    "account_size",
    "start_date",
    "end_date",
    "tick_replay",
    "fill_pricing_mode",
    "exit_candles_path",
})


def variant_payload(payload: dict) -> dict:
    return {key: value for key, value in payload.items()
            if key not in _CONTEXT_KEYS}

Both IDs come from the same serialization and fingerprinting path. That is important: two parallel implementations would eventually disagree about a default or nested field.

Fill modeling belongs to run context. Switching from candles to tick replay can materially change measured results, but it does not create a new trading idea. It creates a more faithful evaluation of the same idea.

Preserve old run IDs during migration

Historical filenames and checkpoints already depended on the original full-configuration hash. I kept that hash byte-for-byte as the run fingerprint and added only the variant fingerprint.

The migration reconstructs every historical payload through the same production functions used for a new run, then backfills the variant columns. Afterward, a simple filter returns every evaluation of one edge across dates and fill assumptions.

The migration also exposed how much apparent experimentation was repeated measurement. Several historical runs collapsed into fewer distinct variants. That is useful information in itself.

Small abstraction, quiet bugs

An independent review found that parameters for one strategy were being threaded into the fingerprint of unrelated strategies. Those unused values could fragment a variant even though they had no effect on behavior.

It also found a schema hazard: appending new fields to an unmigrated CSV could place values under the wrong headers. Both cases now fail loudly, and guard tests keep the migration’s defaults aligned with the live configuration.

The design lesson is broader than backtesting. When an object is evaluated repeatedly, the thing being evaluated and the conditions of one evaluation need separate identities.

Without that split, reproducibility tells you how to recreate a file. With it, you can also ask whether the same idea held up somewhere else.

This post covers backtest system design for educational purposes, not investment advice. Historical evaluations do not guarantee future results.

While reviewing losing trades in a 0DTE divergence strategy, two patterns kept bothering me. Some entries appeared to fight a nearby moving average. Others fired when the stochastic oscillator had only just qualified instead of reaching a deeper extreme.

Those were hypotheses, not filters. I wanted to test them without changing the entry logic.

Add context before adding rules

The signal detector already knew which bar qualified. I extended its output with the market state at that moment:

• the oscillator value at the signal
• signed distance from price to several moving averages
• direction, so “near resistance” and “near support” are analyzed separately

Each value is calculated once and written to the signals CSV. The strategy takes exactly the same trades as before.

An analysis script then joins signals to completed trades and reports linear and rank correlations alongside bucketed win rates. The first pass suggested that signals deeper in the oscillator’s extreme zone performed differently from those that barely qualified.

That is not enough evidence to promote a rule. It is enough to define the next experiment: test a threshold out of sample and compare the filtered variant against the unchanged baseline.

The distinction matters. Instrumentation produced a hypothesis; it did not prove an edge.

The bigger failure was run bookkeeping

While adding the new columns, I ran into a more basic trust problem. I had accumulated manual variant labels, handwritten commands, and output files whose configuration was not recoverable from the filename.

Worse, a forgotten label could let two configurations share a checkpoint. A restarted backtest might resume from signals generated under different parameters without saying so.

I replaced the label with a deterministic identity derived from the full configuration:

canonical configuration
  → SHA-256 fingerprint
  → short collision-aware run ID
  → indexed outputs and checkpoints

The same configuration receives the same ID. Change anything that can affect the result and the ID changes. Each invocation is recorded with its configuration, output summary, and reproducible command.

This removed a human step and made accidental checkpoint reuse much harder.

Cold review found the quiet bugs

An independent review of the diff found three gaps I had missed:

1. The list of hashed parameters could drift from the function signature.
2. An exit path changed candle resolution based on which file existed, but that input was missing from the fingerprint.
3. Resuming an older checkpoint could mix valid new feature values with missing ones.

None changed the strategy logic. All could change what I believed about a result.

I added guard tests for parameter parity, included hidden data dependencies in the fingerprint, and made incompatible checkpoints fail visibly.

I also simplified the run index. Instead of expanding every strategy parameter into a growing set of CSV columns, each row stores one canonical JSON configuration. The index stays stable while individual strategies evolve.

Trust is a backtest feature

This work did not improve the reported performance of the strategy. It improved the chain of evidence:

• the signal row preserves the context I want to study
• the trade row records the outcome
• the run index records how both were produced
• the identifier prevents unlike runs from sharing state

That is less glamorous than a new entry rule. It is also what makes the next rule testable.

This is an educational account of backtest tooling, not investment advice. Historical results do not establish future performance.

On matched trades, the gap was too large to explain away as ordinary slippage. The backtest had turned a losing period into a winning one because it was answering two questions that minute candles cannot answer reliably:

1. Which exit condition happened first inside the bar?
2. What price could the order actually receive?

For a path-dependent exit such as a trailing stop, those are not details. They are the result.

A candle has no sequence

Suppose one minute has both a low below the stop and a high above the next trailing level. OHLC records both extremes but not their order.

My engine resolved that ambiguity too favorably. It could register a new high, ratchet the trail, and book a profitable exit even when the live path had touched the stop first.

The candle model also filled at theoretical levels without observing the market’s actual prints. The combined bias was directional, not random, so optimizing trail width against it meant optimizing against a broken measuring instrument.

Replay the tape, in order

I rebuilt the exit simulation around timestamped option trades. For each historical position, the engine now:

1. loads the contract’s prints during the holding window
2. sorts them in timestamp order
3. updates the running high on every print
4. applies stop, target, trail, and time rules in sequence
5. lets the first satisfied condition win

The candle engine remains available as a lower-fidelity baseline. Tick replay is opt-in so I can compare the two models on the same entries.

The result changed direction. The optimistic candle run became a losing tick-replay run and moved much closer to the observed live behavior. That did not prove the live strategy was sound. It showed that the previous backtest had overstated it.

Trades delivered more value than missing quotes

I expected NBBO quotes to be essential for realistic spread modeling. The data plan available to this experiment included trade prints but not the historical quote endpoint.

That limitation forced a useful test: were ordered prints enough to remove the dominant bias?

On the matched panel, they were. The residual difference between tick replay and live fills was small relative to the correction from intrabar ordering. Prints also contain some realized spread information: the trade that triggers a sell stop often occurs near the bid rather than at a frictionless theoretical level.

This is a conclusion about this sample, not a universal claim that quotes do not matter.

I deleted the correction that looked more realistic

I briefly tested a synthetic spread calibrated from a limited month of quote captures. Applying a flat half-spread made one comparison look better.

It was also the wrong model:

• trade prints already embedded some spread, so the adjustment double-counted it
• a flat value ignored volatility, time of day, liquidity, and time to expiry
• the calibration could not be validated in periods without quotes

A visible limitation was preferable to an untestable correction tuned to one window. Real quotes can support a quote-based fill mode later; a constant chosen because it improves a chart should not quietly become historical truth.

Instrument the instrument

Tick data has its own failure mode: sparse prints. Each replayed trade now records the number of prints in its actual holding window and a simple fill-quality status:

ok | sparse | no_trades

That flag does not repair thin data. It prevents the engine from presenting a low-confidence path as equally trustworthy.

The review caught two important implementation errors before the change landed: a timestamp fallback that could misread epoch units, and a quality metric that counted the broader scan window instead of the position’s hold window. The full test suite now covers both.

The strategy still has to earn confidence through new evidence. But the backtest now distinguishes what it observed, what it inferred, and where the tape was too thin to know.

This is an educational backtesting case study, not investment advice. Tick replay and historical results do not predict future profitability.

In live runs, the trail sometimes triggered faster than my polling loop could explain. So I recorded the option’s tick-by-tick path and measured pullbacks that recovered before the next high.

The first result was useful: nearly half of the recovered pullbacks in the sample were deeper than the live trail. The stop was sitting inside ordinary movement for those trades.

But “make it wider” was not a complete answer.

Typical trades and rare runners wanted different things

When I replayed several trail widths, the median trade favored a tighter exit. Total return favored a wider one because a few large moves dominated the aggregate.

That is a product decision disguised as a parameter choice:

• optimize the common trade and cut give-back
• or tolerate more give-back to remain exposed to rare runners

A single fixed trail cannot maximize both objectives. Before changing live behavior, I needed to know whether I could identify the regime early enough.

The smarter gates arrived too late

I tested several prototypes: option-path confirmation, entry-time volatility and trend filters, and early follow-through in the underlying.

None improved on a simple fixed trail in this small sample.

The entry-time features did not separate the regimes. The feature that did show promise—whether the underlying continued in the trade’s direction—resolved too slowly. By the time the signal became informative, the option had often completed the move I wanted the trail to manage.

The underlying was explaining the regime on a minutes-long clock. The option was repricing on a seconds-long clock.

That mismatch is easy to miss when every observation ends up in the same spreadsheet row.

Then the validators disagreed

I compared matched trades across three sources:

The gap was too large to call slippage. The backtest and the live system were measuring different paths.

My initial hypothesis focused on spread and fill assumptions. That was plausible, but not yet proved. Minute candles also hid the order of events inside each bar, which is decisive for a trailing stop: did the option hit the stop first, or make a new high first?

I left the live parameter unchanged and treated the wider trail as a paper experiment. More importantly, I stopped treating the candle backtest’s absolute result as evidence until I could replay the actual sequence of prints.

That next test changed the diagnosis. The follow-up rebuilds fills from ordered tick data and separates the largest source of bias from the costs I had only inferred here.

What I kept

Three lessons survived the revision:

1. Measure the path, not only the outcome. Path-dependent exits need path-level data.
2. Do not out-clever a small sample. A more adaptive rule is not automatically a better one.
3. Validate the validator. Backtest, paper, and live results are different evidence and should stay labeled that way.

This was one month and a few dozen matched trades. The findings were provisional—but provisional and measured was still better than confident and guessed.

This experiment is educational and is not investment advice. Backtests and paper results do not establish future profitability.

That was enough until I wanted the data available for analysis. The useful change was not simply “upload CSVs to S3.” It was deciding which failure should be allowed to affect which part of the system.

Local persistence remains the source of truth

After a journal row is written successfully, the bot calls a small S3 upload helper. The destination bucket comes from an environment variable, and the upload is a no-op when cloud sync is not configured.

The sequence matters:

close trade
  → append journal row locally
  → confirm local write
  → attempt cloud sync
  → warn, but preserve the row, if sync fails

The upload sits outside the local write’s exception handler. Otherwise, an S3 outage could produce a “journal write failed” error even though the row was safely on disk. That message would be both alarming and wrong.

Local durability and remote availability are separate outcomes, so the code reports them separately.

The S3 client is initialized lazily and reused by the long-running process. The object key also separates raw inputs from future analytics outputs:

landing/journals/<year>/<filename>

The bot writes only to the landing prefix. An analytics job can read from there and write curated tables elsewhere under a different role. The boundary keeps permissions and ownership understandable.

Historical data was the harder part

New uploads solved only the next trade. The existing archive contained several journal schemas from different stages of the bot:

• an early, smaller schema with one symbol and one entry price
• a transitional options schema
• the current account-scoped schema with separate underlying and option fields

I built the migration around the data that actually existed, not the schema I wished had existed. It detects the source shape, maps fields conservatively, calculates only derivable values, and leaves unavailable fields empty.

The natural deduplication key combines strategy, entry time, and contract. Existing annual rows win over imported archive rows. The migration writes backups before modifying an annual journal and produces the same result when run again.

That idempotence matters because migrations rarely happen once. They get interrupted, reviewed, rerun, and occasionally resumed months later by someone who has forgotten the original assumptions.

Git was not the first thing to remove

Once S3 existed, removing journals from Git looked obvious. Operationally, it was premature.

When a tracked file is deleted in a commit, another machine that pulls the change also deletes its local copy. That is correct Git behavior and a poor surprise for a stateful production host.

So I kept the existing backup path until the S3 flow was validated end to end. The sequence is now:

1. Upload new rows reliably.
2. Reconcile local journals against S3.
3. Test restoration.
4. Only then remove the files from version control in a coordinated change.

The takeaway is not that object storage is complicated. It is that adding a new durable path does not make the old one disposable on day one.

Design the handoff for partial success: a trade journal can be safe locally even when cloud sync is down, and a migration can stop halfway without destroying the history it is trying to preserve.

This post describes system design, not investment advice.

My bot originally assumed one process, one account, and one trade journal. Launching it twice would have sent both processes into the same CSV ledger. Positions, P&L, and recovery state could be mixed before I noticed anything was wrong.

The feature was not “run the bot twice.” It was “make every side effect belong to exactly one account.”

Give each process an identity

Each bot instance now receives an explicit account selection and derives a non-secret label for operational output. That label scopes three things:

• its trade journal
• its log file
• every notification it sends

The filenames follow a pattern like this:

2026_perma_journal_<account-label>.csv
permabot_<account-label>.log

Separate journals also mean separate file locks. One process cannot block or corrupt another account’s write, and cumulative results are calculated from the correct history.

The label is useful for observability, but it is not authorization. Credentials stay in environment variables, and neither the label nor a real account identifier belongs in source control or public logs.

Fail loudly when identity is missing

The most important behavior is what the bot refuses to do.

If an operator selects an account whose credentials are not configured, startup fails. It does not fall back to the primary account. A silent fallback could place the intended trades twice in one account while leaving the other untouched.

For software that can move money, an explicit failure is safer than a plausible guess.

I applied the same rule to alerts. My first implementation added the account label inside the notification helper. It worked, but the text at each call site no longer matched the message that was actually sent. I moved the label into the call sites so the source shows the complete alert.

That is a small readability choice until something breaks near the close. Then “what you read is what gets sent” becomes an operational feature.

Migrate history without gambling on it

Changing the journal convention created a data migration. Existing files had to move to account-scoped names without losing prior trades or overwriting a newer target.

I used a small idempotent migration:

1. Resolve the old and new paths.
2. Stop if the target already exists.
3. Preserve the original until the move succeeds.
4. Make a second run a no-op.

“Solo project” does not make historical state disposable. If a system resumes from files, renaming those files is a production change.

Isolation revealed the next shared dependency

The account-level files are now independent, but the processes still depend on shared brokerage authentication state. A token refresh in one process can invalidate the in-memory token held by another.

That is the next boundary to fix: one component should own refresh, while the workers adopt the latest valid token instead of racing to rotate it.

The broader lesson is simple. Multi-account support is not duplication. It is identity carried consistently through configuration, persistence, observability, and failure behavior.

When software trades unattended, “it runs twice” and “the two runs cannot confuse each other” are very different standards.

This is an engineering case study for educational purposes, not investment advice.

In any software project, maintaining a clear ticket hierarchy is essential for organizing work, ensuring accountability, and driving efficient development. In this post, I’ll break down the different ticket types used in JIRA and how I structure them for my Permabot project.

Understanding JIRA Ticket Types

JIRA provides several ticket types, each serving a specific purpose. Here’s how I categorize them:

• Epic – A high-level deliverable representing a scoped user value.
• Story (User Story) – A feature or user interaction that enhances the product.
• Bug – An unintended behavior that needs fixing.
• Task – Non-development work, such as data backfilling or customer interactions.
• Subtask – The smallest unit of work, breaking down a Story, Bug, or Task.

A well-structured hierarchy ensures clarity in ownership, progress tracking, and smooth execution.

Example: Permabot’s Ticket Hierarchy

Here’s how I structure JIRA tickets for Permabot:

1. Epic: Clearly defines end-user value and deliverables.
2. Stories: Break down the epic into actionable work.
3. Bugs: Track issues that arise during testing.

JIRA Ticket Breakdown Example

For Permabot v2.3.1, the Epic started with these high-level goals:

• Improve logging to capture delta values for option legs, enabling better risk assessment and strategy adjustments.
• Implement dynamic contract sizing to limit potential losses to a maximum of 3% per trade on a $21,000 account.
• Enhance logging for HTTP errors to improve debugging and system reliability.

Here’s how my JIRA hierarchy appears in the timeline view:

During development, the number of features expanded due to scope creep. While this is natural, as deeper exploration surfaces additional issues and opportunities, it’s crucial for a product manager to monitor and manage scope effectively. As a general rule, I allow developers to add necessary stories when changes to existing code are required to deliver on the original goals. For instance, before enhancing HTTP error logging, it may be necessary to implement basic logging first. However, external stakeholders should not bypass the product manager when requesting additional features directly from developers.

Another key takeaway is that the Epic initially had zero bugs, but as development progressed, unexpected behaviors surfaced—especially given that the software is still evolving despite being at version v2.3+. This is normal. Logging these issues ensures they are addressed appropriately, whether as immediate fixes (P0 priority) or for future consideration (P1+ priority). I’ll cover prioritization strategies in a separate post.

Example Changelog: Permabot v2.3.1

Here’s a real changelog from one of Permabot’s releases:

## [2.3.1] - 2024-XX
### Added
- Configured max delta to 0.20 and stop loss is 1.75x
- Created Utils function to log response / requests for debugging
- Dynamic sizing defaulting to 3% max loss on 21000 act
- Added push notifications for active monitoring, alerting in event of 401
- WBPR Bot: Refactored William's Brown Price Reversion strategy supporting >1 daily entries
- Introduction of Perma Journal
- WBPR Bot: standardized notifications
- Json dump utils with logger support

### Fixed
- monitor_and_exit loop continues forever when there are http errors, in case connection comes back.
- WBPR Bot: no trade days end the bot

Final Thoughts

A well-defined ticket hierarchy in JIRA helps ensure a structured and scalable software development process. By clearly defining Epics, Stories, Bugs, and Tasks, teams can streamline execution and maintain better control over project progress.

How do you structure your JIRA tickets? Let’s connect and share insights!