[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-80892":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":8,"htmlUrl":8,"language":9,"languages":8,"totalLinesOfCode":8,"stars":10,"forks":11,"watchers":12,"openIssues":11,"contributorsCount":11,"subscribersCount":11,"size":11,"stars1d":11,"stars7d":11,"stars30d":13,"stars90d":11,"forks30d":11,"starsTrendScore":11,"compositeScore":11,"rankGlobal":8,"rankLanguage":8,"license":14,"archived":15,"fork":15,"defaultBranch":16,"hasWiki":17,"hasPages":15,"topics":18,"createdAt":8,"pushedAt":8,"updatedAt":19,"readmeContent":20,"aiSummary":21,"trendingCount":11,"starSnapshotCount":11,"syncStatus":22,"lastSyncTime":23,"discoverSource":24},80892,"tf.why","Raj-glitch-max\u002Ftf.why","Raj-glitch-max",null,"Python",35,0,34,1,"Apache License 2.0",false,"main",true,[],"2026-06-12 02:04:08","# tf-why\n\n**Terraform tells you *what* drifted. `tf-why` tells you *who* changed it, *when*, and *how*.**\n\n![tf-why Demo](docs\u002Fassets\u002Fterminal_demo.gif)\n\n[![CI](https:\u002F\u002Fgithub.com\u002Ftf-why\u002Ftf-why\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Ftf-why\u002Ftf-why\u002Factions)\n[![PyPI](https:\u002F\u002Fimg.shields.io\u002Fpypi\u002Fv\u002Ftf-why.svg)](https:\u002F\u002Fpypi.org\u002Fproject\u002Ftf-why\u002F)\n[![Python](https:\u002F\u002Fimg.shields.io\u002Fpypi\u002Fpyversions\u002Ftf-why.svg)](https:\u002F\u002Fpypi.org\u002Fproject\u002Ftf-why\u002F)\n[![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-Apache%202.0-blue.svg)](LICENSE)\n\n---\n\n## ⚡️ The \"Aha!\" Moment\n\nTerraform plan shows you a resource is being \"updated in-place\". But the logs are silent. You need to know if that security group rule was added by a senior dev during an incident or by a script gone rogue.\n\n**Don't dig through CloudTrail. Just pipe it to `tf-why`.**\n\n```text\n$ terraform show -json plan.tfplan | tf-why\n\n  aws_security_group.web  (ingress rules changed)\n  ├── Changed by:   john.doe@company.com\n  ├── When:         2 days ago\n  ├── Via:          AWS Console\n  └── Event:        AuthorizeSecurityGroupIngress\n\n  aws_s3_bucket.assets  (versioning changed)\n  └── Changed by:   ci-deploy-role\n      ├── When:         1 day ago\n      └── Event:        PutBucketVersioning\n\n2 drifted resources found.\n```\n\n---\n\n## 🛠 Features\n\n- **Instant Attribution**: Maps Terraform resource changes to specific CloudTrail events.\n- **Root Cause Analysis**: Identifies if a change was made via Console, CLI, or SDK.\n- **High-Fidelity UI**: Clean, tree-like terminal output for better readability.\n- **Zero Config**: Works with your existing AWS credentials and Terraform plans.\n- **Privacy First**: Read-only access to CloudTrail; plan parsing happens entirely locally.\n\n---\n\n## 🏗 Why This Convinces Senior Devs (Architecture)\n\nGeneric tools just search CloudTrail for any change. `tf-why` is smarter:\n\n1.  **Strict Resource Mapping**: Uses a precise `Mapper` system that understands the relationship between Terraform resource types (e.g., `aws_db_instance`) and their corresponding CloudTrail event sources and names (`rds.amazonaws.com`, `ModifyDBInstance`).\n2.  **Contextual Intelligence**: It doesn't just show the last event; it uses the plan's `before` and `after` states to narrow down the exact API call that caused the drift.\n3.  **Parallel Querying**: Queries CloudTrail in parallel to ensure attribution completes in seconds, even for large plans.\n4.  **Security**: Requires only `cloudtrail:LookupEvents` permissions. No write access, no secrets, no database needed.\n\n---\n\n## 🚀 Installation\n\n```bash\npip install tf-why\n```\n\n**Requirements:**\n- Python 3.9+\n- IAM Permission: `cloudtrail:LookupEvents`\n\n---\n\n## 📖 Supported Resources\n\nOver **27** critical AWS resources are supported out-of-the-box, including:\n- **Networking**: VPC, Security Groups, Subnets\n- **Storage**: S3 Buckets, Policies, Versioning\n- **Compute**: EC2, Lambda, ECS, EKS\n- **IAM**: Roles, Users, Policies\n- **Database**: RDS Clusters, DynamoDB\n\n---\n\n## 🤝 Social Proof & Proof of Work\n\nCheck out our [Real-World Proof](docs\u002Fassets\u002Ftf_why_real_aws.png) showing attribution on a production-grade infrastructure drift.\n\n---\n\n## License\n\nApache 2.0\n","tf-why 是一个用于分析 Terraform 资源变更原因的工具，能够追踪到具体是谁、何时以及如何改变了资源。其核心功能包括即时归因、根因分析和高保真终端输出，通过将 Terraform 资源变化与 CloudTrail 事件精确映射，帮助用户快速定位变更源头。该工具支持超过27种AWS关键资源类型，如VPC、S3桶、EC2实例等，并且只需要读取CloudTrail事件的权限即可运行，保证了安全性与隐私性。适用于需要对基础设施即代码（IaC）环境下的意外更改进行快速诊断与修复的场景。",2,"2026-06-11 04:02:42","CREATED_QUERY"]