메뉴
Trigger Pattern TEMPORAL flag (required) - Inject Into Breadth agents, depth-state-trace
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/PlamenTSV/plamen --skill temporal-parameter-staleness명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Trigger Pattern Always (run during recon TASK 0, not breadth) - Inject Into Recon agent only (meta_buffer.md enrichment)
Trigger Pattern Always (run during recon TASK 0, not breadth) - Inject Into Recon agent only (meta_buffer.md enrichment)
Trigger STABLESWAP_FORK flag (fork-ancestry detects Curve/StableSwap parent via get_d/get_y/ramp_a/StableSwap patterns) - Agent Type general-purpose (standalone niche agent, 1 budget slot)
SKILL.md 표시 중
SOC 직업 분류 기준
| name | temporal-parameter-staleness |
| description | Trigger Pattern TEMPORAL flag (required) - Inject Into Breadth agents, depth-state-trace |
Trigger Pattern: TEMPORAL flag (required) Inject Into: Breadth agents, depth-state-trace Purpose: Analyze cached parameters in multi-step operations on Sui for staleness when capability holders change them mid-operation. Time source on Sui is the shared Clock object at address 0x6.
epoch|period|duration|delay|cooldown|lock_period|timelock|
unbonding_period|claim_delay|withdraw_delay|maturity_time|
clock::timestamp_ms|tx_context::epoch
Find all operations that span multiple transactions:
| Operation | Step 1 (Initiate) | Wait Condition | Step N (Complete) |
|---|---|---|---|
| {op_name} | {module::initiate_fn}() | {wait_condition} | {module::complete_fn}() |
Sui-specific multi-step patterns:
Time sources on Sui:
clock::timestamp_ms(clock: &Clock): Real-time milliseconds. Shared object at 0x6. Monotonically increasing. Used for time-based delays.tx_context::epoch(ctx: &TxContext): Epoch number. Incremented roughly every 24 hours. Used for epoch-based staking/unstaking.For each multi-step operation:
For each parameter used across steps:
| Parameter | Stored In | Read At Step | Cached? | Admin-Changeable? | Re-Validated At Completion? |
|---|---|---|---|---|---|
| {param} | Shared config object | initiate() L{N} | YES/NO | YES/NO (requires {CapType}) | YES/NO |
| {delay_param} | User's receipt object | initiate() L{N} | YES (in receipt) | YES/NO | YES/NO |
Sui caching patterns:
Red flags: Parameter is cached at Step 1 AND changeable via admin capability AND NOT re-validated at Step N.
For each cached parameter that can become stale:
Scenario A: Parameter INCREASES between steps
1. User initiates at Step 1 with param = X (stored in receipt)
2. Admin (via AdminCap) changes param to X + delta in shared config
3. User completes at Step N
4. Impact: {what happens with stale value X when current is X + delta}
Scenario B: Parameter DECREASES between steps
1. User initiates at Step 1 with param = X
2. Admin changes param to X - delta
3. User completes at Step N
4. Impact: {what happens with stale value X when current is X - delta}
BOTH directions are mandatory -- increase and decrease often have different impacts.
Sui-specific staleness vectors:
PTB bypass check (CRITICAL): Can Steps 1 and N both be executed within a single PTB?
clock::timestamp_ms comparisons): bypassed -- same Clock timestamp within a PTBtx_context::epoch comparisons): bypassed -- same epoch within a PTBFor each parameter updated from an external source:
clock::timestamp_ms (continuous) vs tx_context::epoch (discrete)? Is the choice appropriate?clock::timestamp_ms() returns milliseconds; external sources (Pyth publish_time, cross-chain timestamps) typically use seconds. Any comparison or subtraction without ×1000 conversion → FINDING.For fee/rate parameters that apply to existing state:
| Parameter | Applies To | Retroactive? | Impact |
|---|---|---|---|
| {fee_param} | {what it affects} | YES/NO | {if retroactive: who is harmed} |
Pattern: Fee changes that affect already-accrued rewards or already-initiated operations are retroactive.
Sui-specific retroactive patterns:
For each staleness issue:
Severity factors specific to Sui:
{CONTRACTS} -- Move modules to analyze
{MULTI_STEP_OPS} -- Identified multi-step operations
{CACHED_PARAMS} -- Parameters cached at initiation
{ADMIN_PARAMS} -- Admin-changeable parameters (via capability)
{DELAY_PARAMS} -- Delay/cooldown parameters (clock or epoch based)
{FEE_PARAMS} -- Fee/rate parameters that may apply retroactively
{CLOCK_USAGE} -- Functions using clock::timestamp_ms
{EPOCH_USAGE} -- Functions using tx_context::epoch
| Field | Required | Description |
|---|---|---|
| multi_step_ops | yes | List of multi-step operations found |
| cached_params | yes | Parameters cached across steps |
| staleness_vectors | yes | How cached params can become stale |
| retroactive_fees | yes | Fees applied retroactively |
| finding | yes | CONFIRMED / REFUTED / CONTESTED |
| evidence | yes | Code locations with line numbers |
| step_execution | yes | Status for each step |
| Step | Required | Completed? | Notes |
|---|---|---|---|
| 1. Enumerate Multi-Step Operations | YES | ||
| 2. Identify Cached Parameters | YES | ||
| 3. Model Staleness Impact (both directions) | YES | ||
| 3 (PTB bypass check) | YES | Can Steps 1+N execute in same PTB? | |
| 3b. Update Source Audit | YES | ||
| 4. Retroactive Application Analysis | YES | ||
| 5. Assess Severity | YES |
After Step 2: If cached parameters are admin-changeable via capability -> MUST complete Step 3 with BOTH increase and decrease scenarios.
After Step 3 (PTB bypass): If PTB bypass is possible -> escalate severity (time controls are ineffective). Only hot-potato receipts enforce multi-transaction separation.
After Step 4: Cross-reference with SEMI_TRUSTED_ROLES.md for capability holders that change these parameters -- is the parameter change within or outside the role's stated trust boundary?