Spaces:
Running
Running
File size: 3,512 Bytes
e610a2f ee37d63 e610a2f ee37d63 e610a2f | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 | # Agent Team Rules
## Purpose
Rules define what each agent may decide independently and what requires
validation or user approval.
## Default Permissions
Agents may:
- search local docs and code
- propose factor or model candidates
- create dry-run scripts and focused tests
- generate JSON/HTML validation reports
- update documentation and compact memory notes
## Guarded Changes
These require coordinator approval, QA evidence, and explicit user approval
before production integration:
- `models/predictor.py` feature columns, thresholds, labels, and overlays
- `services/recommendation_service.py` scoring and BUY/SELL/HOLD behavior
- `services/predictor_service.py` cache publishability and production result
acceptance
- `scripts/precompute_hot20.py` and `scripts/precompute_queried_stocks.py`
- Hugging Face publishing behavior
- Telegram daily BUY recommendation content
- `docs/validation_registry.json`
## Evidence Rules
- External survey evidence is not local proof.
- A passing unit test is not accuracy proof.
- A higher overall accuracy is not enough if BUY precision drops under
precision-first mode.
- A higher overall accuracy is not enough if SELL precision drops under a
protected SELL objective. The config may be kept as `candidate_only`, but it
must not be labeled `strict_golden`.
- A candidate that passes only on one small sample should be rerun on a larger
stock set before integration.
- Factor weights must stay inside the documented search range. For current
multi-factor overlay work, that range is `0.00 <= weight <= 1.00`.
- Zero-weight factors are allowed only when the run explicitly permits them.
Current research candidate runs allow at most 5 zero weights; strict
all-factor participation runs require all selected weights to be non-zero.
- Optional external data factors, such as broker big-player power or manually
exported chip scores, must remain zero/missing when the source data is
unavailable. Do not infer them from public OHLCV volume.
- Runtime overlay configs may use only factor names supported by
`models/multi_factor_overlay.py`. A search-harness factor is not
production-adjacent until the equivalent runtime calculation exists.
## Factor Design Rules
- Prefer split factors when one aggregate mixes different trading actions:
support bounce, support break, resistance rejection, and resistance breakout
should be separate candidates before being recombined.
- Prefer combine or interaction factors when several highly correlated risk
factors all push the same side. For example, high base, high-volume upper
shadow, bullish upper shadow, and short-term battle should be tested as a
confirmed exhaustion cluster instead of independent SELL add-ons.
- Use gates for regime filters. ADX, volatility regime, market breadth, and
chop filters should usually enable/disable other factors rather than directly
add BUY or SELL probability.
- Keep horizon-specific logic separate. Intraday/short-term factors should not
silently share one global weight with medium- or long-term momentum factors.
- If a factor improves accuracy by mostly increasing one class, report the
class mix, BUY/SELL precision, and signal ratio before calling it useful.
## Conflict Resolution
When agents disagree:
1. QA correctness issues override implementation convenience.
2. No-lookahead concerns override promising metric gains.
3. User-stated metric priority overrides default gates.
4. Production safety overrides speed.
|